Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62705
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.187 cause and error)
Message-ID: <50444120.40407@lsces.co.uk>
Date: Mon, 03 Sep 2012 06:33:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <CAAyV7nH5Qy=socRTKE5mvpctf_mT-LHFk8eug1QcDeYa+N15vA@mail.gmail.com> <50443843.9030004@lerdorf.com>
In-Reply-To: <50443843.9030004@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Exceptions Vs Errors
From: lester@lsces.co.uk (Lester Caine)

Rasmus Lerdorf wrote:
> On 09/01/2012 06:39 PM, Anthony Ferrara wrote:
>> So, while I know there's some discontent about having the core raise
>> exceptions, let me ask the question differently:
>>
>> Without moving to exceptions, how could the current error and error
>> handling mechanisms be improved to make the scenario I posted above easier.
>> To make handling errors just as easy as ignoring them (or preferably
>> easier)...?
>>
>> Thoughts?
>
> I think there are other options here. Our current error handling isn't
> all that different from how it would be if everything was an exception.
> Chances are that common code isn't going to distinguish between the
> exceptions anyway and they will end up just doing:
>
>    try {
>      file_put_contents(...);
>    } catch (Exception $e) {
>      error_log($e->getMessage());
>    }
>
> Then the more aware folks will be checking their error logs and noticing
> certain errors they may want to handle better and they add explicit
> catches for this:
>
>    try {
>      file_put_contents(...);
>    } catch (NotWritableException $e) {
>      page_an_op();
>    } catch (Exception $e) {
>      error_log($e->getMessage());
>    }
>
> In our current system the before and after would be:
>
>    file_put_contents(...);
>
> And when the same aware person notices a specific condition they want to
> handle they change it to:
>
>    if(!is_writable(...)) page_an_op();
>    else file_put_contents();
>
> The Exception case runs extra code only when the condition happens while
> our current system typically has the check before trying to do the
> operation so there is an extra cost for each op, but there are cases
> where you really don't want it to even try so there is some advantage
> there. Of course a similar check can be added before the call in the
> Exception case.
>
> My point here is that these two systems aren't actually that different
> and the try/catch approach is certainly more verbose. I would also hate
> to end up in the situation where most code has a high-level generic
> exception handler that spews huge meaningless stack traces as a
> catch-all and so far removed from the context of the actual error that
> you can't do anything intelligent about it there.
>
> So how else could you approach it?
>
> My biggest beef with exceptions is that often you end up catching them a
> couple of levels above where the error actually occurred and you don't
> have any sort of recovery context at that point. Common Lisp had the
> notion of conditions and restarts to address this. I always found them a
> bit cumbersome syntax-wise, but I liked the idea of condition objects
> carrying the context of the error. A condition is similar to an
> exception in some ways except it carries contextual data about the error
> and it isn't necessarily exceptional/fatal if not handled. This
> particular characteristic of condition objects appeal to me for PHP
> because it would allow us to migrate everything to conditions, not just
> the fatal errors, without breaking everything.
>
> The second part of the Lisp approach is the restart. If you choose to
> handle the condition you can also choose to try to gracefully recover by
> passing the condition object which includes the context of the error to
> an appropriate restart function that lives closer to the code that
> actually caused the error. This split allows you to have catch-all type
> of condition handlers without losing the ability to do context-aware
> error recovery.
>
> I would love to see a proposal from someone who understands
> condition-restart systems inside out for how they might be applied to PHP.

Thanks Rasmus ... I think that wraps the current state of affairs up nice and 
succinctly. Certainly the 'inconsistent' level of exception states are part of 
the problem here and why personally I'd rather loose them than add more ... 
try/catch always seems like 'I can't be bothered so just do this if you can' 
where it would be much tidier if file_put_contents(); was written so it simply 
finished with an error if it has a problem?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk