In response to a previous post benchmarking exceptions, Volker Dusch has posted some of his own thoughts and benchmarking results on the same topic.

Some days ago there was a blog post regarding php exception performance in 5.4 and the numbers got reported all over the place. The actually numbers are secondary. The main point is: Don't trust "random" stuff on the Internet when thinking about improving your application performance. You always need to measure things for your self and take care doing so! I've initially trusted the benchmark myself and disgraced the whole post saying: "Well yes, exceptions are slower than if statements but nice that they got faster".

He includes some results with a bit more standardized testing - one run with both 5.3 and 5.4 using XDebug and another with it turned off for both. His results make sense, if you think about them:

So what we learn from that? Running stuff with debugging tools is slower than not doing that. That's why we don't use xDebug in production.

Gonzalo Ayuso has a new post to his blog today looking at the performance of PHP exceptions and how it could effect your application's overall speed.

Sometimes we use exceptions to manage the flow of our scripts. I imagine that the use of exceptions must have a performance lack. Because of that I will perform a small benchmark to test the performance of one simple script throwing exceptions and without them.

His (little) benchmarking scripts are included - both looping 100000 times, one throwing an exception and the other not. The results were pretty obvious - the memory usage was about the same but the speed was about ten times faster without the exceptions (in PHP 5.3). In PHP 5.4, however, the numbers were closer as far as time to run. Obviously, unless you make super heavy use of exceptions, you're not even going to come close to something like this (micro-optimization anyone?).

On PHPMaster.com today there's a new tutorial from Sneha Heda looking at error handling in PHP - the types of errors that can come up, how to throw your own and how to catch them appropriately.

Errors are the most common event a developer faces when programming. [...] To help reduce the number of errors in your code, and to mitigate their effects, proper error handling is essential in your web application. This article is a crash course in PHP error handling. You'll learn about PHP's built-in error reporting levels, and how to handle errors with custom error handlers and exception handling.

She starts with the different error reporting levels PHP offers, everything from the lightweight E_NOTICE out to E_ALL|E_STRICT. With this as a reference, she shows how to create a custom error handler (using set_error_handler). Also included is a look at exceptions and some of the more detailed information that comes with them - line numbers, messages, file the error was thrown from, etc.

On NetTuts.com today there's a new tutorial showing you the "ins and outs" of using exceptions in PHP - throwing them, handling the result and integrating them into your error handling process.

Still returning false whenever a function in your program fails? In this article, we'll learn about PHP exceptions, and how you can use them to soup up your application's error handling.

The include some of the methods you can call on your exceptions (including getting the message, code, file, line and the results of a debug_backtrace right before it was thrown). Included is code to throw exceptions, catch them with a try/catch and using error codes as return values and extending them to fit your own needs.

Gonzalo Ayuso has posted a handy tip to his blog today about showing errors even with "display_errors" being off in your application (could be helpful in debugging those difficult problems).

Shared hosting are cheap, but normally they don't allow us the use some kind of features. For example we cannot see the error log. That's a problem when we need to see what happens within our application. Normally I work with my own servers, and I have got full access to error logs. But if we cannot see the error log and the server is configured with display errors = off in php.ini (typical configuration in shared hosting), we have a problem.

His solution involves an "error sniffer" script that captures the issues in a script and echoes them out at the end. In his ErrorSniffer he sets up a custom error, exception and shutdown handler to grab the problems and capture them for later use - including echoing them out to the user if desired.

Lars Tesmer has an alternative to testing xceptions in PHPUnit that's a bit more flexible than just a docblock comment definition.

My main issues with this way of expecting exceptions are: The expectation is pretty far away from the location you'd normally expect to find an assertion. Usually, an assertion can be found at the bottom of each test function, whereas with the current method PHPUnit uses, it's at the top of the test-function. Additionally, it's an annotation "buried" in a comment which is easy to miss. Finally, PHPUnit will watch for an exception thrown by any of the code inside the test-function.

To replace it, he's created an "assertThrowsException" test that takes in the exception type to test for and the code to test for the exception (via a closure). He has his proof-of-concept posted on github if you'd like to give it a try. This also allows you to test for more than one exception in the same test, possibly as a result of slightly different conditions.

David Stockton has a new tutorial posted to his blog - a technique he's found useful in his Zend Framework application to make the ErrorController work with Ajax calls to reduce the message you get back to just a JSON response.

If you've ever built a Zend Framework MVC app which makes AJAX calls, you may have noticed that if an error occurs, you'll get a chunk of JSON followed by the HTML for the error page. If you've built a layout, you'll get all of that back to. This is fine if your users hit the page in the browser but it can cause problems with your JavaScript being able to correctly decode your JSON.

The fix is pretty simple, though, and only requires that you add the error handling action to the Ajax context to force it to drop the layout and any other HTML that might come along with the view. He includes a bit more code to have the error handler include the exceptions and pass them out to be included in the JSON response.

Slawek Lukasiewicz has a helpful hint posted to his blog today about handling type hinting failures in a what he sees as a "more correct" way than just throwing an error - throwing an exception when the hinting criteria's not met.

One of the most annoying behavior of PHP type hinting feature is triggering error instead of throwing exception when instance type is invalid.

By default, a failure generates a "catchable error" that, thanks to the custom error handling methods PHP includes, can be correctly handled. He includes a snippet of code that defines the errorHandler method that checks the error type for E_RECOVERABLE_ERROR and throws the exception (an ErrorException) if found.

Jani Hartikainen has a new post with a gotcha he came across when using typehinting in exceptions and methods.

A small gotcha I recently ran into: If you use typehinting, PHP never checks that the class your typehint specifies actually exists!

He includes simple examples that define the class type hint as some random string and PHP never throws an error for it. He also notes that it's even worse when dealing with namespaces - how it handles exceptions locally unless you specify otherwise. Of course, these "features" can be put to good use in the right situations, but they can be confusing for a developer without a keen eye.

On DevShed today there's a new tutorial posted talking about the Liskov Substitution Principle (part of the SOLID set of principles) and how to use it in a practical example using some object-oriented PHP.

However, not all is bad with Inheritance. When used properly it can be a great ally. The question that comes to mind is: how can you keep away from building derivatives that behave totally different from the chosen abstraction(s)? Here's exactly where the Liskov Substitution Principle (LSP) comes into play.

They choose to illustrate the principle in the form of a view renderer that, when an unintentional issue happens, throws a new exception. He creates the abstract class to generate the view objects and creates a few child objects that extend it. using these, he creates a set of templates that render a header/footer/body with the data given. The problem comes up when he tries to work with his objects and a partial view instead of a composite view is passed in.

It's a complicated situation to follow, but it does help make the principle a bit more clear. I'd suggest following it all the way through and possibly even trying out their code (included) to make it even more clear.