Since I had done some PHP benchmarking last week, I wondered about the performance implications of a technique that I use sometimes. In this article I take a quick look at some benchmarks to prove it’s worth.

PHP has a number of faults. One of them being that it has two different models for handling errors. In this post I show you how to catch errors as exceptions in existing code. Also, I do some benchmarks to see if this is even a good idea.

AOPHP was apparently started in early 2005 as a research project by John Stamey and Bryan Saunders but for unknown reasons it did not get popular and was loosely maintained for a number of years.  Since about 2007, the topic hasn’t really been talked about much.

One of my personal rules of using PHP is to Never Suppress Errors (except in production). I follow this rule because it keeps me from shooting myself in the foot, and generally I try to avoid that.

PHP supports a number of different scope models for error suppression, which can be combined to produce sophisticated (or atrocious) use of errors. They seem to fall into a few categories; Per-environment, per-file, and per-command.

Per-Environment — Globally configured via PHP.ini, this is imperative for a production environments that you want to hide messy errors from. For example, you wouldn’t want to hand out a stack trace to potential hacker or burden a casual user with cryptic error messages. Error suppression at this level is usually smart and can be part of good security.

Per-File — PHP doesn’t just enforce a single global rule, but also supports overriding the above environmental setting manually. Since PHP is stateless, this change only applies to the current page lifespan, or until it is manually turned off — which can be useful for certain scenarios like showing errors. Or vice versa, not showing errors, the choice is yours. Generally these statements are less than sublime, but all-in-all, they are easy enough to find and do only one thing.

Per-command — Finally, PHP supports per-command error suppression in the form of an ‘at’ symbol “@”. This is the one I have always told myself NEVER TO USE! It’s not that I’m paranoid, it’s just impractical to go through ALL of your code and add/remove these symbols whenever you move to production.