Re: PEAR_Error, ErrorStack, Exception, and compatibility

Justin Patrin wrote:

1) In general, we're supposed to be moving to PEAR_ErrorStack instead of PEAR_Error. It's smaller, more flexible, and is a very nice system for debugging as well as error handling. 2) Developing code which deals with return values is just as valid as dealing with Exceptions. It's a different way of doing things. As many people have said, they believe that Exceptions are only for excptional circumstances and would rather use a return value.

What I've seen in docs on PEAR_ErrorStack suggests that it does not use return values. I see it as being rather similar to exceptions in that way. It's another way of handling errors, but unlike exceptions it doesn't actually require you to handle things. This type of error handling has existed in the past -- e.g. early Phing for PHP4 used a try()/catch() system that was stack-based. Using exceptions has the distinct advantage that it forces users to handle errors. In return-code or stack based error handling you can ignore errors or just forget to check for them, making for much more bug-prone code. I also believe that exceptions are for exceptional circumstances, i.e. I don't build apps anticipating errors.

try { $class->func(); try {

    //do something
    //do more

} catch(Exception $e) {

    die('there shouldn't be an exception here');

} } catch(Exception $e) { } //go on or: try { $class->func(); $ok = true; } catch(Exception $e) { $ok = false; } if($ok) { //do something //do more } //go on Neither of those is nice looking code.

Neither of those is well-designed code, either. I think *when* you actually start developing using exceptions, you will realize that most of the time you don't care where it failed and the times when you do you will refactor your code such that you're not doing large code flow changes based on the presence of errors. Boolean return values (which aren't errors) certainly have their place; e.g. you can check if things are going to work rather than just trying them & see if an error happens. Consider, this real-world pseudo code: function hydrate($rs) { $v = $rs->getInt(1); if (PEAR::isError($v) { return $v; } $this->id = $v; $v = $rs->getString(2); if (PEAR::isError($v) {

    return $v;

} $this->name = $v; } vs. /** @throws Exception */ function hydrate($rs) { try {

    $this->id = $rs->getInt(1);
    $this->name = $rs->getString(2);

} catch (Exception $e) {

     throw new Exception("Error hydrating.", $e);

} } That's more typical in my experience; in example above calling code doesn't care what minute part of hydration failed (but can access that info through nested exception if desired). I can send you lots of examples off list if you like. The only places where I've seen issues like the one you mention above is when you're trying to take something built for PHP4 and turn it into exception-based error handling without looking at the bigger picture and fixing the code design.

"[One of] the main problems seen with exceptions [is]:

    * Overuse of Exception Handling
      Some people attempt to do all their Error Handling using Exceptions. This will end in unreadable code full of trying and catching."

This is true, as shown above. Not all errors should be Exceptions.

So you think Andreas was suggesting mixing return value error handling with exceptions? What a mess. Certainly, you should use trigger_error() for warnings and you should use boolean return values from methods like isReadable() to anticipate problems before blundering into them. Your code doesn't have to be a mess of try/catch to do error handling using exceptions.

In refleciton, I think what all these debates do illuminate is that the upgrade path to PHP5 is anything but easy. Sure you can upgrade to PHP5 but not use any PHP5 features; that will certainly make the upgrade easier, but why upgrade at all then?

1) Because it will allow you to use your PHP4 packages with little to no changes, *side by side with* PHP5 packages. As has been said by many, unless you reassign $this, PHP4 code should run fine in PHP5 (non-E_STRICT). 2) Because it allows an easy upgrade path. You start by using what you have, then rewrite to use new features *as you can*, not necessarily all at once. 3) Because it allows flexibility and ease of use.

But why upgrade any packages to PHP5? -- you didn't answer my question. If you're going to require that PHP5 packages don't use PHP5 language features, then why shouldn't those packages just be writtein in PHP4. Asked another way, what can I gain for my package by using PHP5? I use PHP5 for interfaces, exceptions, ppp, & other PHP5-only features that are not compatible w/ PHP4 packages. I can always use an existing PHP4 package if needed; in fact, if I need to use PEAR packages I just re-throw PEAR_Error as Exceptions from my calling code. I don't think there's anything keeping people from using PHP4 code from PHP5 code. The question is more about whether to down-play PHP5 features so that it's "easier". You're welcome to, but don't ask me to. Hans