Sameer Borate has a new post to his site today showing how you can handle multiple exceptions in PHP 7.1, the latest release in the PHP 7.x series.

Exception handling is one of the ways in which modern languages handle errors. PHP usually handles exception in a separate catch block for each different type of exception. Below is a example exception code that uses three custom exceptions ‘MyFooException’, ‘MyBarException’ and ‘MyBazException’ that is later handled in a ‘try’ block.

He includes a bit of code showing the "old way" of doing it with multiple catch statements, one for each type of exception. With PHP 7.1 however, you can collapse all of those down into a single catch statement and type hint each type you want caught (pipe delimited). This can make for much cleaner code and a lot less repetition in your error/exception handling.

Aaron Piotrowski has a new post to his site talking about a feature of the next major release of the PHP language (PHP 7) around error and exception handling: working with throwable exceptions and errors.

Handling fatal errors in the past has been next to impossible in PHP. A fatal error would not invoke the error handler set by set_error_handler() and would simply halt script execution.

In PHP 7, an exception will be thrown when a fatal and recoverable error (E_ERROR and E_RECOVERABLE_ERROR) occurs, rather than halting script execution. Fatal errors still exist for certain conditions, such as running out of memory, and still behave as before by immediately halting script execution. An uncaught exception will also continue to be a fatal error in PHP 7. This means if an exception thrown from an error that was fatal in PHP 5.x goes uncaught, it will still be a fatal error in PHP 7.

He goes on to talk about the new interface that both Fatals and Errors implement to make catching them possible in PHP7: Throwable. He provides an example of what the interface would look like in PHP code and how to catch them (a simple try/catch). He then gets into each of the types and looks at the error and exception types they cover including TypeError, ParseError and AssertionError. He also includes an interesting part at the end of the post showing you how to write your error/exception handling to work correctly with both PHP 5 and PHP 7 at the same time.

In this new post to his site Chris Hartjes gives an example of what he calls a "testing smell". This particular illustration deals with the poor handling of testing and exceptions with try/catch blocks.

As part of a project to migrate the PHP code at work from PHP 5.2 to PHP 5.4, I’m using our extensive test suite to look for instances where something that changed between the versions of PHP that we are using has caused some unexpected behaviour. In one of our code bases, I found some tests that are exhibiting a test smell through their use of a try / catch block in the test itself.

He includes a (contrived) example showing the use of an exception in a unit test to run an assertion in the "catch" for the test to pass. He points out that this particular check is being done to see if the user input is valid...and that it's a bad way to enforce it using exceptions. He also suggests that if you have an "if" situation, don't use one test with logic in it, write two tests. He mentions a disenting opinion but notes that a failing test is a failing test, regardless of what caused the failure.

Joshua Thjissen has a new post to his site today about a feature that's been introduced in the upcoming PHP 5.5 release of the language - the addition of "finally" to try/catch exception handling. He gets into it a bit more technically than just the "introductory" level, discussing parent/child exception handling and using returns.

Exception handling is available in PHP since version 5. It allows you to have a more fine-grained control over code when things go wrong ie, when exceptions occur. But since PHP 5.5, exception handling has finally evolved into what it should have been from the beginning: the "finally" part has been implemented.

He includes a basic example showing how a certain part is always executed, regardless of if the exception is thrown or not. He also shows how a "chained catch" would work to catch multiple kinds of exceptions and when the "finally" is run as it relates to the "trickle down" handling of exceptions. He then gets a little more complex and introduces "return" into the mix. Of special note, even if you return, the "finally" will still get called.

Vance Lucas has a quick new post to his site showing you how to handle exceptions in Gearman tasks so that they can be logged correctly as a failure.

I recently had some issues with Gearman tasks throwing exceptions and killing the whole Gearman daemon. This made it nearly impossible to trace errors back to their origin, because the logged exception stack trace didn’t provide much useful information, because it just logged where it failed in Gearman. [...] The only other place to add code that will catch exceptions for all jobs run is in the GearmanWorker::addFunction method.

To solve the issue, he ends up passing in a closure that takes in the $task and wraps its execution in a try/catch to handle the exception correctly. This is then thrown to a custom exception handler and logged for future diagnosis.

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

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.

There's two new posts that look at an up and coming PHP IDE (really a PHP plugin for an existing IDE) - NetBeans - one from Mike Borozdin and another from Juozas Kaziukenas.

Here's some of Mike's comments:

NetBeans is mostly known for Java developers as a good and free IDE. At the same time recently NetBeans started supporting other languages, like C/C++, Ruby and finally PHP. Moreover it not only supports plain PHP, but it offers quite good support of HTML and JavaScript. [...] Generally, I feel pretty good about NetBeans. It seems to be working much faster than Eclipse, both in terms of the loading time and in terms of code editing and code completion as well.

And some thoughts from Juozas:

I find more more articles about NetBeans 6.5 IDE for PHP, for example this Mike's article. Why people like it so much? After some weeks spent reading all these articles, I finally decided to throw away all other editors and try new-and-shiny NetBeans. [...] Overall it's just a wonderful tool - stable, helpful and being actively developed. Give it a try!

DevShed has start up a new series today with the first part in a four-part series looking at exception handling in PHP5.

If you do any serious programming, whether it's in PHP 5 or some other language, you've needed to know how to handle run time errors and other "exceptional" conditions. You can do this by making your program throw generic exceptions. Or you can unlock the potential of PHP 5 and learn how to create custom exceptions, which is the subject of this four-part series.

In this first part they get you started with exceptions, showing how to throw them and catch them correctly (try/catch). They put it to good use in an example catching exceptions thrown from a MySQL connection and select.

In a recent blog entry Stefan Priebsch shows how to take an error thrown by your script and turn it into an exception (to make things like catchable fatal errors).

While I would personally prefer an exception to be thrown in the first place, it is pretty easy to convert errors to exceptions in PHP.

His example is pretty simple - you set a custom error handler in your script that pulls in the error information and tosses an exception based on the error number the handler is given. Then you can use the try/catch method to see if your script has tossed an exception of the fatal error type. Nice simple solution to handle an interesting little problem.