I'm pleased to release our first ever round table, where we place a group of developers in a locked room (not really), and ask them to debate one another on a single topic. In this first entry, we discuss exceptions and flow control.

The opinions vary among the group as to what exceptions should be used for (even outside of the flow control topic). Opinions shared are things like:

• Exceptions are situations in your code that you should never reach
• Errors cause Failures and are propagated, via Exceptions.
• So, essentially, exceptions are an "abstraction" purely to model the abnormality.
• Personally, I envision exceptions more as "objections."
• Exceptions like this should be caught at some point and transformed into a friendly message to the user.

There's lots more than this in the full discussion so head over and read it all - there's definitely some good points made.

Zend Framework 2.0 recently passed Milestone 1 on its development track and is rocking on PHP 5.3 in all its namespaced glory. Milestone 2 is the introduction of the new Exception regime to ensure all of the frameworks' fun components throw Exceptions that are specific enough to be useful. Why waste your idleness on the Devil's work when you can be bringing salvation to armies of PHP programmers?

He links to some great resources if you want to get involved including the list of who's working on the exceptions handling, a link to the components and maintainers list for the framework and at getting started with Git guide to introduce you to the version control you'll need to use.

What's the most common pattern for error handling you see in beginner's PHP code? - That's right, do_X() or die('do_X failed);. That's nice and all, as at least you have some sort of error handling, but I think this way of handling errors must go. There is no place for it in modern PHP code - it's the worst way to handle errors, not much better than not handling them at all.

He talks about why die() is so bad and some alternatives to it - trigger_error (with a custom error handler) and exceptions. When used correctly, these two can help your script correctly catch and handle errors without the mess of a die().

Before PHP5 one had to resort to specific return values or drastic measures like trigger_error(). Planning exceptions, I found out, is just as important as class design. At any point where a developer needs to handle the possibility of an exception being thrown he needs to know: what Exceptions can I expect and what Exceptions do I plan to catch? In this post I'll show some important aspects to consider when planning exceptions.

He starts off with a basic example of an exception, throwing it and catching it, as a part of a SOAP client sample and looks at things to catch, how to catch them and doing fun things like rethrowing and extending basic exception types.

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.

They explain each step of the way, giving you the code you'll need to attach to the current working script, making this delegation possible. They look briefly at tpye hinting and simple exception handling in the script before hitting you with a full-blown Exception handler class to improve your script's reliability.

There's a few different error handling types that Damien mentions

Welcome to the last part of the series "Error Handling in PHP." In two parts, this series introduces the basics of error handling in PHP. It demonstrates some of the most common methods for manipulating errors in PHP 4, and explains the implementation of exceptions in PHP 5, particularly in object-oriented environments.

They introduce things like try/catch blocks as well as more complex items like custom exceptions and exception subclassing. They start with the basics, but quickly move into grabbing more detailed error information, working with the various error types, and extending the Exception class with subclasses to make it more flexible...]]> Thu, 19 Jan 2006 06:53:22 -0600