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.

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.

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.

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

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.

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!

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.

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.

A useful new feature in PHP 5 is exception handling via the try/throw/catch paradigm. An exception may be thrown and caught. If an exception is thrown in code surrounded by try, the following statements will not be executed, and the exception will be handled by the first matching catch block.

He gives a high-level overview of how Exceptions in PHP5 work and includes a simple example from his work with his DIY Framework.

I just noticed today, that PHP's try catch blocks require curly braces. Anybody has an idea why it is like that? I have used curly braces by default up until now, so I just stumbled upon this weirdness today.

He includes two examples, one with a curly brace after the catch clause and the other without. This is different than several other control structures (like ifs) that don't require the curly brace when there's only the one line following it.