Rob Allen continues his posts looking at the use of the Slim PHP framework with this new post about logging errors.

Slim Framework 3 is being actively developed at the moment and has a number of changes in it, including the use of the Pimple DI container and an overhaul of pretty much everything else! In this post, I'm going to look at error handling. The default error handler in Slim 3 is SlimHandlersError. It's fairly simple and renders the error quite nicely, setting the HTTP status to 500. I want to log these errors via monolog.

He includes the code to first set up the Monolog logger and inject it into the dependency injection container. Then he creates a custom error handler that extends the Slim handler but overrides the __invoke method to log the message in addition to displaying it. Finally he registers the error handler into the DI container as the "errorHandler" instance so Pimple correctly knows how to throw errors.

Giorgio Sironi has a new post to the DZone.com Web Builder Zone today giving a high-level guide to some of the PHP errors you could encounter in your development time.

While pure object-oriented languages produces mainly exceptions to signal an error, PHP started out as procedural and so it has a wide range of errors that can be raised along with exceptions.

He talks about a few of the most common error related issues:

• Exceptions
• Errors
• Error Types (E_NOTICE, E_PARSE, etc.)
• php.ini directives
• PHP functions for setting error handlers

Rob Allen has another Zend Framework-themed post to his blog today looking at handling exceptions in front controllers a bit more correctly than they're currently treated.

If you have a Zend Framework Front Controller plugin which throws an exception, then the action is still executed and then the error action is then called, so that the displayed output shows two actions rendered, with two layouts also rendered. This is almost certainly not what you want or what you expected.

He points out the more correct process it should follow - dispatch the request and catch the error there before the request continues. The error is then tossed to the error controller for correct handling. He includes the code to do just that, showing how to wrap the routing in a try/catch and push the exception over to the error controller with an "error_handler" plugin created with an exception type of "other".

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.