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

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

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

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

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

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) {

}


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.