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.

The PHP Developer Blog has a quick post for the unit testers out there on how to work with exception handling in your tests.

When unit testing, you'd also want to test whether your application throws Exceptions as expected (the following examples are based on SimpleTest). Assumption for the examples is, that we have a method that expects an integer as parameter.

Putting the assertion inside of the catch block won't work correctly since it wouldn't happen unless an exception is thrown. Instead he recommends putting it right after the exception try/catch and check to see if the exception variable is a type of 'Exception' (with another potential solution of adding in a check for an 'InvalidArgumentException').

In this new entry to his blog Quinton Parker looks at some strangeness he's found around the try/catch functionality in PHP. His specific example involves file_get_contents.

PHP never ceases to amaze me. Just the other day a colleague discovered that you can suppress error messages reported by file_get_contents() using the try-catch statement. That should've raised an eyebrow.

His sample code shows the normal error that a file_get_contents on a nonexistent file would give then wraps it in a try/catch. The same path is put into the file_get_contents but, because of some sort of interesting handling, isn't reported in the catch. He's at a loss and is asking for help figuring this one out from the readers out there. Be sure to leave a comment if you have more info.

DevShed has start up a new series today with the first part in a four-part series looking at exception handling in PHP5.

If you do any serious programming, whether it's in PHP 5 or some other language, you've needed to know how to handle run time errors and other "exceptional" conditions. You can do this by making your program throw generic exceptions. Or you can unlock the potential of PHP 5 and learn how to create custom exceptions, which is the subject of this four-part series.

In this first part they get you started with exceptions, showing how to throw them and catch them correctly (try/catch). They put it to good use in an example catching exceptions thrown from a MySQL connection and select.

Michelangelo van Dam has written up a quick introductory post on his blog about the process around throwing and catching exceptions in your apps.

One thing that I noticed was that although the code was well written [in the Zend Framework], implementing coding standards and best practices on many of the classes, I did notice a wrong usage of throwing exceptions (the try - catch statements).

He gives a few examples - catching a "divide by zero" the right and wrong way, how to grab/handle the message that comes along with the exception and how to define your own custom exception handler to help your code do more useful things with the errors it might throw.

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.

On his blog today Martynas Jusevicius talks about a feature that was new in PHP5 - Exceptions:

A useful new feature in PHP 5 is exception handling via the try/throw/catch paradigm. An exception may be thrown and caught. If an exception is thrown in code surrounded by try, the following statements will not be executed, and the exception will be handled by the first matching catch block.

He gives a high-level overview of how Exceptions in PHP5 work and includes a simple example from his work with his DIY Framework.

Chris Hartjes has posted again about the "rebirth" of a Zend Framework component he's worked on - the Zend_Service_Audioscrobbler.

So, dear readers, I received some nice emails and comments from those you have used Zend_Service_Audioscrobbler, along with having a nice email conversation with Wil Sinclair from Zend.

He still wants to "rip things up and start over", but has decided on a slightly different route - mapping the older function calls to the new ones via a __call catch and including a message stating that the older function call would be deprecated.

In working with his code recently, Tim Koschuetzki noticed something odd with a block of try/catch code:

I just noticed today, that PHP's try catch blocks require curly braces. Anybody has an idea why it is like that? I have used curly braces by default up until now, so I just stumbled upon this weirdness today.

He includes two examples, one with a curly brace after the catch clause and the other without. This is different than several other control structures (like ifs) that don't require the curly brace when there's only the one line following it.

Exceptions and warnings can be tossed out from your code at some odd locations sometimes. There's a few options that you have when they jump out, including pushing them out to an error log or just ignoring them completely. Alexander Netkachev has a different solutions, though - handling them with something already built into PHP, using exception reporting.

This coding tip demonstrates how to deal with PHP core notices and warning (aka recoverable errors) in the exception way, using try/catch statement.

IT's a simple idea, but it can definitely help you keep all of you errors in one place. The sample code he gives shows both a basic idea of the solution and a bit more complex example, providing more detailed messages for different exception types.