Jani Hartikainen poses an interesting question on his blog today - is it more correct for a function, having failed at its job, to return a value of throw an exception.

You have created a nice, well written function, but you realize you forgot something: The failure case. What should a function do when it fails? There are two schools for this - the "throw an exception" school and the "return an error value" school. But which of these is the correct approach?

He suggests that this debate has stuck around from the time when there weren't exceptions in several popular programming languages and that returning the value was the only valid way. He touches on what an exception condition is (with a few code examples) and situations where each choice might be the right way to go.

Brandon Savage continues his introductory series on exception handling in PHP with this new post to his blog. This time the focus is on methods for nesting exceptions.

In the last two entries we have talked about the concept of layer abstraction: that is, that exceptions should not be allowed to pass out of one layer and into another. So, when an exception is raised in the database layer it should be caught in the controller. But how do we go about making sure that exceptions raised in the database layer are properly recorded and processed, ensuring that we have error logging and don't simply silence our exceptions?

He looks first at general exception nesting then at extending the base Exception class to write more nested code (inside a class). He also touches on the nested exceptions that were included in the latest release of the PHP 5.3 series.

Brandon Savage has posted the next part of his series looking at exceptions in PHP. This new article shows how to create a custom exception layer on top of the built-in handling.

One of the things that you can (and should) do with PHP exceptions is extend them to suit your own purposes. While the base Exception class in PHP is neither abstract nor impossible to use on its own, extending exceptions give you a great amount of flexibility and power, particularly in three areas: customization, identification, and abstraction.

He looks at creating custom exception types (for easier handling and customization and how it can help with the abstraction of your applications.

In a new post to his blog Brandon Savage looks at exception handling in PHP with an introduction to a novice user of PHP:

Exceptions make it easy to interrupt program flow in the event that something goes wrong. They allow you to customize how a program handles errors, and gracefully degrades an application. This week, we will discuss various exception handling techniques, and today we will discuss the basic dos and don'ts for exceptions.

He starts with what exceptions are, how they should be used and a few handy tips that can help you make the most out of this handy PHP5 feature like:

• Exceptions are not meant to be silenced
• Use exception codes to differentiate between exceptions
• Exceptions are meant to be handled
• Don't use exceptions to manage normal program flow
• Be sure that your exceptions honor layer abstraction

DevShed has posted the second-to-last part of their tutorial series about creating a Twitter "badge" for your site with the custom icon and latest tweet pulled from the site. This new part looks at handling exceptions thrown by their class.

This application serves a single purpose. It accepts an input and delivers an image to the browser. In the event of an error, the script halts execution and displays that error. The problem lies in this difference in output. The calling page is expecting an image and therefore won't display the error text. So to make this useful, it might be a good idea to deliver the error text as an image instead.

They show you how to build the custom exception handling interface and the code to create the exception that will use it.

According to this new article on the PHPFreaks.com site the use of "or die()" in scripts...must die!

I see it all the time, and I see people telling other people to do that all the time. It's plain simply bad practice and it's time that people start to understand this. When I confront people with it they usually say something along the lines of "oh, but it's just for debugging purposes". Okay, so I tend to put echo and var_dump() statements in my code for debugging as well. However, this is not the same.

They list several reasons why the "or die trick" is a bad idea including the non-catchable error that's thrown and that there's no control over where the error message from die goes. As a better alternative, they suggest using trigger_error and the exception handling built into PHP5 to correctly catch any potential errors a statement might throw.

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').

Brian Moon has called for the death of die():

Now, I have no actual authority to do so. My PHP CVS karma does not extend that far. And I doubt it will actually get removed despite it being nothing more than an alias for exit now. No, what I would like to call a death to is the usage of die such as [echoing out a message to the user instead of doing proper error handling].

He points out a few perfectly viable alternatives like the exception handlers, the trigger_error function and custom error handlers.

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.

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.