With PHP 5 adding exceptions, I imagine that the PHP community will have to undergo a bit of a paradigm change regarding PHP error handling. This transition probably won’t be without controversy and heartache, especially for those integrating third party libraries. I suspect that some of these issues won’t get worked out until 5.1.
Wez Furlong has a proposal for structured errors in PHP. I like the idea of standard error codes. I don’t much care for the exception_map or the superglobal part, though.
Even languages that have had exceptions forever still have controversy over the issue. Joel on Software considers exceptions harmful and favors status returns:
A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be. It is true that what should be a simple 3 line program often blossoms to 48 lines when you put in good error checking, but that’s life, and papering it over with exceptions does not make your program more robust.
Doug Ross agrees with Joel and talks a bit about poor software quality. It almost seems like he is elevating exceptions considered harmful into exceptions kill:
In other words, many of us are undisciplined. We’re more worried about “readability” (and I disagree with that contention as well – but I’ll get to that) than whether or not or software will kill anyone, debit the wrong account by a million bucks, or screw up the actuarial table for 83 year-old transvestites.
I agree with Ned Batchelder’s comprehensive rebuttal in exceptions vs status returns. Bob Balaban comments on this with an anecdote:
Years ago at Lotus one of the architects did an actual benchmark of some code in 123 written first with the status technique and then with the exception technique, and claimed that the exception technique was 15% less code (he was comparing compiled code size) and maybe 5% faster.
Following my API Design principles, I think the smallest amount of code wins. If exceptions can reduce the amount of code, then that is the best way to go. After all, error propagation code can have errors too. Code verbosity considered harmful.
Feed
Subscribe to this blog…
[...] k that people who want to use goto for error handling probably don’t understand how to use exceptions properly yet. (Thinking in C?) Gotos are handy for parsing? Yes, b [...]
One thing that bothers me on the subject of exceptions in PHP is I’ve yet to see anyone in PEAR approach the subject of a standard exceptions. Most languages using exceptions (including Java, Python and Javascript) provide a standard set of exception classes for common issues such as these. This is a great opportunity for PEAR to make itself both invaluable to PHP and right some of the error handling wrongs it’s done in the past.
Think the big plus of exceptions is it provides a standard mechanism everyone can use – the big issue with PHP4 is everyone’s got a different approach and glueing them together, when using different libraries, is often painful. Some people are saying exceptions are slower compared to other flow control structures – haven’t confirmed this for myself but my guess is while it may be true at first glance, it’s not so true when writing real code e.g.
$result = someFunc();
switch ( $result ) {
case ERROR_X:
// Do something
break;
case ERROR_Y:
// Do something
break;
case ERROR_Z:
// Do something
break;
default:
// Do the stuff that happens when there are no errors
break;
}
The cost of evaluating each condition in the switch is incurred every time it’s used while the alternative;
try {
$result = someFunc();
// Do the stuff that happens when there are no errors
} catch (Error_X e) {
} catch (Error_Y e) {
} catch (Error_Z e) {
}
Leaves evaluation of the type of error to only those cases where an error actually occurs (which is hopefully rare).
Personally what I’d like to see is the possibility of being able to trap old style errors in a try catch block (but if you don’t use one, the error propogates to the traditional global error handler). Would allow for code like;
try {
$result = eval($someCode);
} catch (e) {
}
Javascript does a very good job of this – you can even hard code syntax errors and catch them as exceptions. That’s not to say this is the way applications should be designed but there are circumstances where it’s useful and it implies a well implemented exception mechanism. I get the feeling we’re going to end up with a mess in PHP between the old mechanism and the new exceptions.
Would be interesting to discuss error handling strategy in “userland” PHP. Think in helps to consider what type of error we’re having to deal with. Based on the definitions I came up with here some random thoughts;
- Syntax errors: use the old mechanism (programmers will want to fix these immediately) but allow exceptions for special cases like eval() and create_function()
- Semantic Errors: should mainly use the old mechanism (some will be a programmers mistake and something they want to fix) but perhaps exceptions for usage errors (e.g. divide by zero). At the same time if proper validation is being performed, the zero should never get to the function that might divide by it.
- Environment errors: this is where exceptions have something significant to error and should be the mechanism of choice, at least for libraries. Can’t connect to the database, open a file or whatever – throw an exception.
A forth type of error might be “User Errors” but these are question of validation IMO.
could PHP5 be an exceptional mess?
PEAR dev is hot with the exception fever at present, The OO purists are beating down the door requesting the eviction of that horible legacy of a bygone age, PEAR_Error. And hoisting the flag of the Exception god at the gates.Well, It’s not
could PHP5 be an exceptional mess?
PEAR dev is hot with the exception fever at present, The OO purists are beating down the door requesting the eviction of that horible legacy of a bygone age, PEAR_Error. And hoisting the flag of the Exception god at the gates.Well, It’s not
could PHP5 be an exceptional mess?
PEAR dev is hot with the exception fever at present, The OO purists are beating down the door requesting the eviction of that horible legacy of a bygone age, PEAR_Error. And hoisting the flag of the Exception god at the gates.Well, It’s not
could PHP5 be an exceptional mess?
PEAR dev is hot with the exception fever at present, The OO purists are beating down the door requesting the eviction of that horible legacy of a bygone age, PEAR_Error. And hoisting the flag of the Exception god at the gates.Well, It’s not
could PHP5 be an exceptional mess?
PEAR dev is hot with the exception fever at present, The OO purists are beating down the door requesting the eviction of that horible legacy of a bygone age, PEAR_Error. And hoisting the flag of the Exception god at the gates.Well, It’s not
Harry I really like your definition. I agree that exceptions make perfect sense for enviornment errors but not for syntactical or semantical errors. User errors shouldnt be exceptions as they incorrect input should be expected behaviour and if any they would be syntactical mistakes.
Breves y tacañas
Nuevamente, un post escrito con poco tiempo: XML en PHP 5 . Una presentación sobre el infinito mundo de los acrónimos: PHP, XML, XSLT, DOM, SAX… Excepciones en PHP 5: ¿Serán un problema excepcional?, Otro post en el qu…
Could you please send to me the contacts of developer of your site? It looks so damn good!
[...] The coding standards emphasize not reserving global resources. The framework will not define functions or global constants, it uses exceptions and doesn’t reserve __autoload for its own use. This is very good. On the other hand, it seems to rely on static methods quite a bit, which I think can burn you over the long run if you are trying to offer a componentized architecture and can make code more difficult to test. I’ve been moving away from static methods as much as I can in my own code. Eventually, I always seem to regret using them. They lure you in at the beginning with the promise of simplicity and then they punish you later with their inflexibility. [...]