The StarTutorial site has posted the latest in their "Modern PHP Developer" series of posts outlining some of the more recent changes to PHP and its ecosystem that can help you become a better developer. In this latest post they focus on Exceptions in PHP - the types, handling them and when they're most useful.

Since PHP 5 was released, Exception is added to PHP as an object-oriented programming language feature. By definition, an Exception is an exceptional event during program execution. In PHP, an Exception is simply an object (an instance of Exception class). When an exception occurs, PHP will halt current execution flow and look for an handler, and then it will continue its execution by the handler's code. If no handler is found, a PHP Fatal Error will be issued with an "Uncaught Exception ..." message and the program terminates.

The tutorial is then broken down into several parts:

• When to use Exception
• How to use Exception
• Create your first custom exception 5.3
• SPL exceptions
• RuntimeException

For each item in the list, there's a summary of the topic and code examples to help illustrate the points made.

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 the NetTuts.com site today they've posted the transcript of a panel discussion they had with several developers about exceptions and whether or not they should be used for flow control.

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.

In Padraic Brady's latest post he makes a pitch for developers out there to get in on the development of the Zend Framework version 2.0 "before the offer ends" in a few different ways.

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.

Jani Hartikainen has a suggestion for all PHP developers out there - stop using die() for handling errors!

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

Tibo Beijen has a new post to his blog today looking at exception handling starting with some of the basics and moving out to custom exception handing methods.

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.

Exceptions and warnings can be tossed out from your code at some odd locations sometimes. There's a few options that you have when they jump out, including pushing them out to an error log or just ignoring them completely. Alexander Netkachev has a different solutions, though - handling them with something already built into PHP, using exception reporting.

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.

Exceptions and warnings can be tossed out from your code at some odd locations sometimes. There's a few options that you have when they jump out, including pushing them out to an error log or just ignoring them completely. Alexander Netkachev has a different solutions, though - handling them with something already built into PHP, using exception reporting.

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.

Developer.com has posted the next part in their series covering object oriented programming in PHP5, this time focusing on using delegation to enhance the functionality of their prexisting DBQuery class.

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.

Developer.com has posted the next part in their series covering object oriented programming in PHP5, this time focusing on using delegation to enhance the functionality of their prexisting DBQuery class.

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.