In a post to his site Frank de Jonge looks at a few different topics around the idea of "cleaning up after yourself" when it comes to the use of finally, file streams and deferred execution.

Cleaning up after yourself can be a tedious task. For example, closing file handlers after using them needs to be done. A programmer's life isn't all about the happy path. When things go pear-shaped you might end up duplicating cleanup code throughout your code. This is horrible, let's explore an alternative.

He starts by looking at the use of resources for file handling instead of something like file_get_contents. Along with this, however, comes "less happy" things to do around cleanup of the resource in case of error or when complete. He suggests that it can be better handled and, after comparing a PHP function version to a Go function doing the same, refactors to make use of finally to close the resource in one place (and it is always called exception on exception). He refactors it even more by splitting it out into a "cleanup" function that can be reused in other places where resources are accessed.

While not specific to PHP (the examples are in Ruby, in fact) this new tutorial on the Toptal.com blog has some good information and suggestions around the use of exceptions in your applications.

Exceptions require special treatment, and an unhandled exception may cause unexpected behavior. The results are often spectacular.

Over time, these errors, and countless others [...] contributed to the impression that exceptions are bad. But exceptions are a fundamental element of modern programming; they exist to make our software better. Rather than fearing exceptions, we should embrace them and learn how to benefit from them. In this article, we will discuss how to manage exceptions elegantly, and use them to write clean code that is more maintainable.

They start by talking about why exception handling is a good thing and some common practices to help make them more manageable. They suggest that good exception handling can also help make your code more maintainable, extensible and readable in the long run. He suggests creating your own kind of exception hierarchy (more possible in PHP 7) and using them to get more specific on the type of exception that was thrown. He recommends not "rescuing" exceptions more than needed (in PHP this is try/catch) and that it's okay to defer the handling for the exception being thrown and not deal with it right away.

He also reminds you that not all exceptions need handling in your own code (sometimes it's up to the user) and that following conventions on naming can help end users better understand why there's an error. Finally, he recommends logging exceptions as they're major errors in your application, not just data problems or smaller bugs.

The SitePoint PHP blog has posted a tutorial continuing on from some previous advice with even more defensive programming practices you can use in your PHP applications.

Many people argue against defensive programming, but this is often because of the types of methods they have seen espoused by some as defensive programming. Defensive programming should not be viewed as a way to avoid test driven development or as a way to simply compensate for failures and move on. [...] What are these methods, if not ways to anticipate that your program may fail, and either prevent those, or else ways in which to handle those failures appropriately?

They go on to talk about the ideas of "failing fast" when errors happen in your application with an extra suggestion added on - "fail loud" too. The tutorial then looks at four different places where more defensive programming techniques can be applied (and how):

• Input validation
• Preventing Accidental Assignment in Comparisons
• Dealing with Try/Catch and Exceptions
• Transactions

They end with a recommendation that, while you should fail fast and loud when issues come up, be sure it's not to the determent of the overall user experience or sharing messages with users that may just confuse them.

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".

Timothy Boronczyk has written up a nice post about two practical uses of the "goto" syntax in the upcoming PHP 5.3 release of the popular web scripting language.

Yet goto can still be useful under certain circumstances. For example, some programmers use goto to direct the execution flow to dedicated error-handling logic elsewhere in a program in languages that lack exception handling (such as C).

His two examples are to: emulate exception handling in a procedural environment and to overcome perceived limitations with try/catch. He adds in some code comparing the "without goto" and "with goto" versions of the same code showing how the exception handling might be handled differently.

On PHPBuilder, Robert Bernier has started writing a series of articles on Postgres exception handling. In this one, covers the basics of exception handling for PHP developers.

Postgres exceptions are quite different from PHP exceptions; whereas PHP 5 uses the traditional "Try And Catch" format, Postgres exceptions can only be defined, executed and processed inside the body of the function that triggered the exception.

Also in the article he covers RAISE statements, how Postgres handles them, and gives good practices on how to use them effectively as a method of troubleshooting errors.

On PHPBuilder, Robert Bernier has started writing a series of articles on Postgres exception handling. In this one, covers the basics of exception handling for PHP developers.

Postgres exceptions are quite different from PHP exceptions; whereas PHP 5 uses the traditional "Try And Catch" format, Postgres exceptions can only be defined, executed and processed inside the body of the function that triggered the exception.

Also in the article he covers RAISE statements, how Postgres handles them, and gives good practices on how to use them effectively as a method of troubleshooting errors.