Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7813
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20040213194740.02bc65f0@127.0.0.1>
Date: Fri, 13 Feb 2004 19:47:43 +0200
To: internals@lists.php.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 /
  zend_default_classes.c zend_default_classes.h zend_execute.h
  zend_execute_API.c
From: andi@zend.com (Andi Gutmans)

At 08:51 AM 2/13/2004 -0500, George Schlossnagle wrote:

>On Feb 13, 2004, at 8:39 AM, Andi Gutmans wrote:
>
>>At 08:12 AM 2/13/2004 -0500, Sterling Hughes wrote:
>>>What is the reasoning for this new change?
>>
>>The reasoning is that it allows users to do a catch-all (which otherwise 
>>we'd add to the language syntax). It also adds cleanliness to the 
>>Exception hierarchy and allows PHP code to interact with PHP code which 
>>isn't written by the developer knowing that there's a common interface 
>>(such as getMessage()) which the exception always adheres to. That 
>>improves the ability of exception handling especially debugging and 
>>logging significantly.
>
>The above description sounds more like a 'best practice' and less like 
>something that PHP should be forcing on users.  If I explicitly choose to 
>create an exception that must be caught specifically, I don't see why I 
>shouldn't be allowed to do that.

Because, in any case, we would then add a construct to catch all exceptions 
but you'd loose out on the fact that you don't have an interface you can 
rely on.
At the end of the day, if you look at the two alternatives, I think this is 
the best one and leads to much better and robust code.

Andi

-- 
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php