Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5 packages

From: Date: Mon, 23 Aug 2004 18:23:17 +0000
Subject: Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5 packages
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-32856@lists.php.net to get a copy of this message
Pepr wrote:
But: "It was written to cope with Exceptions, introduced in Zend Engine 2 as the error handling mechanism." -1 from here, I do not like the idea to force the usage of exceptions as general errors hanlders. I failed to see why each single package should declare (or extends, or...) their exception classes. Why? I can imagine some without any kind of exceptions...
I tend to agree that classes shouldn't have to implement their own subclasses if they don't want to; however, I recognize that catching package-specific errors is only possible if your package has its own exception subclass. How do you propose catching package specific errors? Maybe that's simply not essential, but it would certainly be useful.
"An error is defined as an unexpected, invalid program state from which it is impossible to recover." This is the definition of an exception. Where exceptions should be used (trying at least to die cleanly ;) ). But in no way the definition of an error. That's exactly where errors and exceptions differ.
I also don't understand what you mean here. Perhaps you could provide some examples of errors that should not be exceptions. I think that it's important to qualify the "impossible to recover", as Sergio did in the sentence that followed: "For the sake of definition, recovery scope is defined as the method scope." So, impossible to recover _for the method_. A connect() method may be critical or trivial depending on the calling application. The connect() method has no way of knowing just how severe the failure of connect() is, so it throws an exception and lets the calling code make that judgement call: perhaps the app should terminate, perhaps it only merits a log line / warning. Exceptions are errors: they are things that aren't supposed to be happening in your code. Exception-based error handling and returncode-based error handling are two different ways of achieving the same end. Exceptions simply provide a number of advantages, as described in the RFC and discussed in more detail on the wiki. -Hans

« previous php.pear.dev (#32856) next »