On Reddit.com there's a discussion that's started up around when to throw exceptions in your PHP applications. The poster asks:

When and where do you throw exceptions? Is it just on database connections? Is it whenever you run a query? Send an email? I'm just curious what the best situations are to throw exceptions and possibly improve my code.

There's a good number of replies so far, some a bit more vague than others:

• "In exceptional circumstances."
• "You throw an except when you can't sensibly handle what has just happened."
• "Fatals for compile-time errors, Exceptions for run-time errors"
• "I throw an exception any time the function being called is either not capable of continuing or it is not going to return the expected results."
• "Exceptions everywhere is not a good thing."

Check out more suggestions and comments in the full post.

On NetTuts.com today there's a new tutorial showing you the "ins and outs" of using exceptions in PHP - throwing them, handling the result and integrating them into your error handling process.

Still returning false whenever a function in your program fails? In this article, we’ll learn about PHP exceptions, and how you can use them to soup up your application’s error handling.

The include some of the methods you can call on your exceptions (including getting the message, code, file, line and the results of a debug_backtrace right before it was thrown). Included is code to throw exceptions, catch them with a try/catch and using error codes as return values and extending them to fit your own needs.

Rob Allen caught an interesting feature of the proposed exception handling in the Zend Framework v2 - the ability to throw an exception and catch it at the interface level, not just the class.

I've been reading the Proposal for Exceptions in ZF2 and like it. One thing that caught my attention was that it suggests that you can catch an interface. I hadn't heard of that ability before, so I pulled out my trusty text editor to have a play.

He creates a basic bit of code - an interface for the exceptions, an SPL exception class and a normal exceptions class - as well as a basic generic class that throws exceptions based on each. The result is that catching exceptions for the class types works as well as catching it on the "ExceptionInterface" level too.

We now have the ability with ZF2 to be able to use different exception classes to represent different error types rather than using string comparison and, at the same time, we can have a single catch() for when we don't need that level of granularity.

DevShed continues their series looking at exceptions in PHP with this second part focusing on throwing and handling customized exceptions in your PHP5 application.

While the built-in exception system that comes bundled natively with PHP 5 is usually good enough to handle errors and other critical conditions during the execution of a given web application, it's worthwhile to mention that there are a number of additional cases where it is necessary to implement an exceptions system that can handle different failures in a more specific way.

They show how to trigger some basic custom exceptions and detail the creation of a class to handle catching these exceptions in a bit more OOP kind of way.

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.

DevShed has posted the next part of their series looking at handling errors thrown by the __autoload functionality of PHP. This time they enhance their previous method and allow for custom error messaging.

In this last article of the series I'm going to introduce some additional modifications to the current signature of the "__autoload()" function to make it throw exceptions that display more useful error messages.

They start by setting up the application to have something to build from (a series of PHP scripts). They add on the exception handling to throw the custom error (the "class not found" they mentioned).

DevShed has posted the next part of their series looking at handling errors thrown by the __autoload functionality of PHP. This time they enhance their previous method and allow for custom error messaging.

In this last article of the series I'm going to introduce some additional modifications to the current signature of the "__autoload()" function to make it throw exceptions that display more useful error messages.

They start by setting up the application to have something to build from (a series of PHP scripts). They add on the exception handling to throw the custom error (the "class not found" they mentioned).

DevShed continues their looks at autoloading classes in PHP5 today with this new tutorial focusing on catching and handling any errors that might be thrown in the process.

This is the third article in the series on how to auto load classes in PHP 5. This article will demonstrate how to trigger exceptions in a way that can be caught by the corresponding "catch()" block. [...] Nonetheless, this issue can be fixed with relative ease. That will be the goal of this third article of the series. So if you’re interested in learning how this solution will be implemented, don’t waste any more time and start reading now!

They start by looking at throwing an exception with the __autoload so that the script can catch it. The go back to mention the method they'd talked about before - using just eval() - and then show the "new and improved" method of handling the result with a try/catch block instead of a direct output.

DevShed continues their looks at autoloading classes in PHP5 today with this new tutorial focusing on catching and handling any errors that might be thrown in the process.

This is the third article in the series on how to auto load classes in PHP 5. This article will demonstrate how to trigger exceptions in a way that can be caught by the corresponding "catch()" block. [...] Nonetheless, this issue can be fixed with relative ease. That will be the goal of this third article of the series. So if you’re interested in learning how this solution will be implemented, don’t waste any more time and start reading now!

They start by looking at throwing an exception with the __autoload so that the script can catch it. The go back to mention the method they'd talked about before - using just eval() - and then show the "new and improved" method of handling the result with a try/catch block instead of a direct output.

DevShed has posted the second part of their series looking at handling exceptions in a PHP5 application today. This one focuses on capturing the errors thrown when your script autoloads classes.

Bearing in mind this intrinsic limitation exposed by the "__autoload()" magic function when it comes to triggering exceptions at runtime, in this second article of the series I'm going to show you some basic workarounds that you can implement to provide this function with the ability to throw exceptions when a determined source class fails to be included.

They give two examples of the use of the __autoload function as well as a method to capture the fatal errors that it might throw (using an eval inside of it to check on the class).