Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59350
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain akbkhome.com designates 202.81.246.113 as permitted sender)
Message-ID: <4F7C1788.6080905@akbkhome.com>
Date: Wed, 04 Apr 2012 17:42:32 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: internals@lists.php.net
References: <4F7BABC8.7040904@akbkhome.com> <4F7BB90B.9040907@lerdorf.com>
In-Reply-To: <4F7BB90B.9040907@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Catchable - marking methods just like static?
From: alan@akbkhome.com (Alan Knowles)

response below...
On Wednesday, April 04, 2012 10:59 AM, Rasmus Lerdorf wrote:
> On 04/03/2012 07:02 PM, Alan Knowles wrote:
>> I just saw Daniel changing some of the PEAR classes to use Exceptions,
>> and it's pretty clear that this could cause havoc with the end users.
>> The problem being that there is no 'soft' landing for the migration
>> process.
>>
>> Users switching code from return style error handling to exceptions are
>> not given any hints about what would be affected, and what may need fixing.
> Couldn't you just use a default exception handler via
> set_exception_handler() to implement a "soft landing" mechanism?
This solves the problem of what happens when an exceptional event 
happens, the system fails (logging something to the error log or 
rendering an error). However does not really fix the consumer issue that 
it expected a return value, not an exception.

However previously when a error occured, it was handed by the checking 
of return value (eg. PEAR::isError()).. This means that all previous 
code that checked for return values has to determine should it check for 
exceptions (try/catch) or does the method still return a error value

This either means that you will have to one of the below.
a) have complete test suites to spot all these exceptional cases
b) do a full code review
c) wait until each exceptional event occurs,  and fix when found..

This obviously is a problem with new code as well, using exceptions in 
PHP is a good luck proposition, anything larger than a small script is 
basically going to either wrap most of the code as try/catch or pray 
that the developer has not forgotten that a particular call may throws 
an exception (I doubt I would be able to do this, so I really do not 
expect others to get this perfect as well).

Rather than this hap-hazard approach to ensuring code is correctly 
handling error conditions would it not be far better for the engine to 
be advising of situations where this may be occurring before they 
occur.. in the same way undefined variables issue warnings.  writing 
code that throws exceptions should throw warnings if it's likely that it 
is not handled.

Alan
>
> -Rasmus
>
>