Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9071
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <407AC236.5030506@chiaraquartet.net>
Date: Mon, 12 Apr 2004 12:22:14 -0400
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Adam Maccabee Trachtenberg <adam@trachtenberg.com>
CC: Ilia Alshanetsky <ilia@prohost.org>,  internals@lists.php.net
References: <1081740243.14476.11.camel@coogle.localdomain> <200404120855.02983.ilia@prohost.org> <Pine.LNX.4.58.0404121039220.1153@miranda.org> <200404121109.44904.ilia@prohost.org> <Pine.LNX.4.58.0404121114370.1153@miranda.org>
In-Reply-To: <Pine.LNX.4.58.0404121114370.1153@miranda.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Exceptions and Errors
From: greg@chiaraquartet.net (Greg Beaver)

Adam Maccabee Trachtenberg wrote:

> I am willing to concede that SQL parse errors aren't the best example
> here, but that doesn't mean extensions should never throw exceptions.

If a user has written code expecting it to work in PHP 4 and PHP 5 with 
a registered error handler, it has to be completely rewritten. 
Exceptions, by nature, can not be caught at the global level and then 
modified, they are local.  Of course, you could just surround your 
global code with a try {} catch {} but that is just about the worst hack 
I can imagine.

Unless there is a way to "resume" execution after the point of the error 
(i.e. exactly how the current error handling works), exceptions will 
only make things more exasperating.  If I have to surround every single 
method call with try {} catch {}, that = a bad design decision.

- say byebye to readability
- what if an extension upgrades and throws a new, more specific kind of 
exception?  instant code breakage, unless the catch-all is not paranoid
- EVERY try {} catch {} will need a catch-all, unless you're willing to 
risk total breakage later.
- error handling is suddenly forced to be directly integrated with 
program logic, and isn't that the opposite of exception handling's goals?

Greg

P.S.

This is what I mean by a "resume" statement:

function blah()
{
     $a = $someobject->throwsexception();
     $nextstatement = 'works?';
}

...

try {
     blah();
} catch (Exception $e) {
     log_exception($e);
     if (thingsareok()) {
         resume; // execution starts at "$nextstatement = 'works?';"
     }
}

Without the ability to resume, we are forced to do

function blah()
{
     try {
         $a = $someobject->throwsexception();
     } catch (Exception $e) {
         $ok = pass_to_global_exception_handler_and_logger($e);
         if (!$ok) {
              throw ($e);
         }
     }
     $nextstatement = 'ack';
}

for even the most minor of error conditions