On the Laravel Daily site they've posted a tutorial showing the Laravel users out there how to create and catch custom exceptions in your application. Exceptions are a useful tool to handle "exceptional situations" where something fails badly enough where the application cannot proceed.

Quite often web-developers don’t care enough about errors. If something goes wrong, you often see default Laravel texts like “Whoops, something went wrong” or, even worse, the exception code, which is not helpful at all to the visitor. So I decided to write a step-by-step article of how to handle errors in elegant way and present proper error information to the visitor.

He uses a "user search" task to help illustrate the methods for creating custom exceptions, catch exceptions and showing the error to the user. Code is included as well as screenshots of the output. With the basics of exception handling out of the way, they move the handling off into a service and take it one step further to create a custom "user not found" exception and its use in the search method.

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.

Ole Markus has a new post today looking at how you can catch fatal errors in your PHP applications a bit more gracefully than the usual failure messages.

In dynamic languages like PHP [errors like E_ERROR and E_PARSE] happen all the time, for example when trying to call a method on a variable you assumed was an instance of a specific class, but which for some reason suddenly was not instantiated. Not only are they often not catched, but often it is also difficult to even know that they are occurring.

His solution comes in the form of a built-in PHP function, register_shutdown_function, that executes when the PHP process is shutting down - errors or not. It takes in a callback method that has access to an exception object. You can get lots of interesting information from this object and, as in his example, log it to a file for future investigation.

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.

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.