Exceptions - A new slant to the argument
| From: | Davey | Date: | Thu, 08 Jul 2004 17:14:19 +0000 |
| Subject: | Exceptions - A new slant to the argument | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-31756@lists.php.net to get a copy of this message | ||
Dear Pears,
my apologies for starting yet another exceptions thread...
but here is my take on this:
There are two camps on error handling - Developers (i.e. us) and users (i.e. them) - this has not been identified.
We are fighting this without taking this into consideration...
Lukas emmited an example of using exceptions if an option in an array is missing, lets take a look at this for a second.
A developer MAY choose to throw an exception at this point - but this exception should NOT reach the user in this form. The exception should be caught by the developer internally in the package.
I think what we need to do is make sure that all errors are given to the USER in one place, and one way. This should be via PEAR_ErrorStack.
The developer can then choose to throw exceptions in the package either by using native:
try {
//code
throw new Exception($msg, $code);
}
catch (Exception $e) {
//handle exception
// push error onto the stack
}
or by throwing the exception object returned by PEAR_ErrorStack::push() like this:
try {
//code
throw $stack->push(...);
}
catch (Exception $e) {
}
The only time an exception should bubble up out of the package internals, is where it is non-recoverable by the package itself - for example if MDB2 can't connect to the database - the users application will likely not work if this fails. Though I feel that we should still use PEAR_ErrorStack here. The only value an exception gives us, is that if the user is lazy and doesn't check the error and halt the script themselves, it will do it automatically.
Another example is, say if XML_Tree2 is passed a malformed XML string (getTreeFromString() IIRC)
We need to make this distinction between Developers and Users - how errors are thrown/handled inside a package is up to the developer - though we should provide some common ways of doing this - PEAR_Error, PEAR_Exception and PEAR_ErrorStack are already implemented/being worked on.
We should then have one agreed way to get our errors back to the user - it would suck for them to have to do this:
$foo = new XML_Tree2;
$foo->addRoot('bar');
if (PEAR::isError($foo) {
//handle error
} elseif (PEAR_ErrorStack::staticHasErrors('XML_Tree2')) {
// handle error
} elseif (/* insert how to check if a PEAR_Exception has occured */) {
// handle error
}
This is how things are going to turn out if we're not careful because Developer A likes PEAR_Error and Developer B likes PEAR_ErrorStack.
By moving all packages to PEAR_ErrorStack for reporting errors to the USER we can ensure that all users code will be:
if (PEAR_ErrorStack::staticHasErrors($anypackage)) {
// handle error
}
Then each developer is free to handle errors however he likes inside his package using one of the three ways pointed out above...
I know I've re-iterated some points here, oh well! I hope you all understand what I'm trying to convey.
- Davey