Miro Svrtan has a new post today proposing something that could be added to help handle bad method calls in PHP apps - using the BadMethodCallException (pre-existing) instead of throwing fatal errors.

Using getter method that is not implemented will get you fatal error saying how undefined method is called and request will stop. [...] On the other hand if you would use public property all you would get is a notice saying how this property does not exist and rest of request would be completed. [...] I know that this is due to dynamic typing behavior of PHP and no I am not suggesting raising a notice if undefined method gets called but since 5.1.0 there is a BadMethodCallException class which would be perfect for this situation.

There's been other people that have proposed the same idea as a bug, but nothing formal has been submitted as an RFC to make the change. Miro is looking for feedback to find if others would be interested in this feature and want to make the proposal (leave comments here).

In a quick post to her blog today, Lorna Mitchell talks about an issue with pecl_outh tat came up during her development of a new API. A strange fatal error message was breaking her connection.

I'd gone through all the handshaking steps, got the acces token and was ready to start talking to the service itself. However when I tried to call OAuth::fetch, I got an error message: Fatal error: Uncaught exception 'OAuthException' with message 'Invalid protected resource url, unable to generate signature base string'

As it turns out, the issue was obscure - the address she was connecting to was missing a training slash (http://api.localhost versus http://api.localhost/) and it was causing the OAuth fetch to fail (apparently undocumented). If you're interested in some of the other things that have come up in her work with OAuth on the project, see here.

Ole Markus has a new post today looking at how you can catch fatal errors in your PHP applications a bit more gracefully than the usual failure messages.

In dynamic languages like PHP [errors like E_ERROR and E_PARSE] happen all the time, for example when trying to call a method on a variable you assumed was an instance of a specific class, but which for some reason suddenly was not instantiated. Not only are they often not catched, but often it is also difficult to even know that they are occurring.

His solution comes in the form of a built-in PHP function, register_shutdown_function, that executes when the PHP process is shutting down - errors or not. It takes in a callback method that has access to an exception object. You can get lots of interesting information from this object and, as in his example, log it to a file for future investigation.

Douglas Brown has posted some hints to help you find errors in your PHP scripts all centered around error reporting settings.

There are several methods to solve errors in PHP code. Sometimes when the user waits to see an output a blank page will be shown if there is an error. To show the errors E_ALL^E_STRICT is used for the PHP 5 version. Contrarily, remaining versions just use E_ALL.

He talks about the log_errors and display_errors settings in your php.ini, the error_reporting function call or a custom error handler as shown in this example from the PHP manual.

On PHPFreaks.com there's a new tutorial providing a beginner's guide to debugging in PHP (with the built in functionality PHP has, not external software).

Everyday the forums see probably hundreds of topics posted where the problem is a fairly simple error. [...] As a beginner, it can be difficult to find and solve these errors. By tackling each of these in turn, I hope to teach you some methods of finding and solving them.

They look at the different sorts of errors - syntax errors, fatal errors, warnings, notices - as well as some of the ones a bit harder to track down like database problems and logical errors.

In a recent blog entry Stefan Priebsch shows how to take an error thrown by your script and turn it into an exception (to make things like catchable fatal errors).

While I would personally prefer an exception to be thrown in the first place, it is pretty easy to convert errors to exceptions in PHP.

His example is pretty simple - you set a custom error handler in your script that pulls in the error information and tosses an exception based on the error number the handler is given. Then you can use the try/catch method to see if your script has tossed an exception of the fatal error type. Nice simple solution to handle an interesting little problem.

From the Nothclick dev blog, there's this new post from Soenke Ruempler that talks about working with error messages in PHP, specifically with fatal errors.

One big issue of the PHP error handling is that there's no built-in way to catch fatal errors with an user-defined error handler. So I thought a little bit about it and maybe you have better approaches or solutions...

With the goal of emailing the developers when such an error is thrown, he comes up with three different "storage methods" - using syslog, sapi, or a common logfile - and two different methods for watching them - file watching and syslogger. He works through these two options, trying to figure out which out be the simplest to implement.

He comes to the conclusion, though, that he might just be better off with one of the packages already out there to do something similar. Of the four he found, Swatch seemed to fit the best. He includes configuration and setup info to illustrate.

From the Nothclick dev blog, there's this new post from Soenke Ruempler that talks about working with error messages in PHP, specifically with fatal errors.

One big issue of the PHP error handling is that there's no built-in way to catch fatal errors with an user-defined error handler. So I thought a little bit about it and maybe you have better approaches or solutions...

With the goal of emailing the developers when such an error is thrown, he comes up with three different "storage methods" - using syslog, sapi, or a common logfile - and two different methods for watching them - file watching and syslogger. He works through these two options, trying to figure out which out be the simplest to implement.

He comes to the conclusion, though, that he might just be better off with one of the packages already out there to do something similar. Of the four he found, Swatch seemed to fit the best. He includes configuration and setup info to illustrate.

While testing the eZ components framework on the latest version of PHP (PHP 5.2), Derick Rethans noticed a problem - a new "Notice" message appearing related to a __get call.

The first issue is an extra notice in some cases. This all works 'fine' with PHP 5.1, however with PHP 5.2 the [following] notice was generated for this code.

The cause? Well, the magic function __get only returns the variables in read mode so they cannot be written to. In Derick's situation, there was a foreach that was trying to use the values in a read/write mode. As a result, the error was tossed. He does provide a workaround, though, involving casting the information into an array.

While testing the eZ components framework on the latest version of PHP (PHP 5.2), Derick Rethans noticed a problem - a new "Notice" message appearing related to a __get call.

The first issue is an extra notice in some cases. This all works 'fine' with PHP 5.1, however with PHP 5.2 the [following] notice was generated for this code.

The cause? Well, the magic function __get only returns the variables in read mode so they cannot be written to. In Derick's situation, there was a foreach that was trying to use the values in a read/write mode. As a result, the error was tossed. He does provide a workaround, though, involving casting the information into an array.