Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69878
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Rowan Collins <rowan.collins@gmail.com>
Message-ID: <526BD0FB.1020809@php.net>
Date: Sat, 26 Oct 2013 15:26:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com> <52699FB5.20300@garfieldtech.com> <526A6BCC.3060502@php.net> <526AC472.8060607@sugarcrm.com> <526AC950.7020605@php.net> <526BB309.4030106@gmail.com>
In-Reply-To: <526BB309.4030106@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: krakjoe@php.net (Joe Watkins)

On 10/26/2013 01:18 PM, Rowan Collins wrote:
> On 25/10/2013 20:41, Joe Watkins wrote:
>> If we really wanted to, we could fix all the code that throws the base
>> Exception, making them throw specialized types, as they should
>
> This seems a little contradictory when you're proposing an
> undifferentiated EngineException, where individual errors would need to
> be distinguished based on the message string. That's pretty much what
> throw Exception('Some message'); gives in userland.
>
> Besides which...
>
>> and include a compiler check that finds catch(Exception) blocks and
>> complains, it shouldn't really be valid
>
> I don't think "catch(Exception)" blocks exist as a partner to "throw
> Exception;" they exist to mark a boundary in code that you don't want
> any exceptions to cross, or where you want to log all exceptions in some
> bespoke way. They might be the last in a long string of catch() blocks
> attached to one try, like the default: label in a switch statement. They
> might also, as discussed wrt assertions/expectations, be in a unit
> testing framework.
>

They _should_ exist as a boundary, a last resort, if at all, but when 
they do exist they are no such boundary or last resort, they are normal 
catch blocks because the core throws the base Exception ... I'm just 
making the observation that it's not a very good idea to do that, 
doesn't take a lot to fix, has no bc issues and sets the right kind of 
standard.

An EngineException is just that, an Exception from the Engine, that 
makes sense, an Exception coming from Date, doesn't make sense, that 
should be a DateException, it's not dependant on or descended from 
EngineException at all, it would just be better form if exceptions 
thrown from the core meant something so that catch all exception blocks 
when they are used are just as we all know they should be - a last 
resort, if present at all.

Maybe emitting a warning is a bit pedantic ...

Anyway, carry on with the discussion at hand, which is not about any of 
this at all, I was just saying it might be nice if we are to start using 
exceptions from core _as a policy_ to make good, as good as possible, 
our use of exceptions so far.

Cheers
Joe