Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12525
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4135CD4B.6040508@akbkhome.com>
Date: Wed, 01 Sep 2004 21:23:23 +0800
User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040805)
MIME-Version: 1.0
To: Alan Knowles <alan@akbkhome.com>
CC:  internals@lists.php.net
References: <4135C8C3.5000705@akbkhome.com>
In-Reply-To: <4135C8C3.5000705@akbkhome.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] parse errors when testing for undefined exceptions
From: alan@akbkhome.com (Alan Knowles)

aghh.. - the previous example was crap

The priciple it was try to make was that

....
    require_once 'MyException.php'
    throw MyException(....);
....

then trying to catch MyException leads to a parse error when it's 
try()'d and not loaded. means we cant lazy load any Exceptions, and save 
file io/memory etc.

Regards
Alan

Alan Knowles wrote:

> This is a simple example of why making a parse error out of undefined 
> Exception types is going to be very problematic.
>
> function test($a) {
>
>    if (!extension_exists('sqlite')) {
>        return;
>    }
>    try {
>        SQLite::query($a);
>           // parse error!!! - if we dont have sqlite, we dont have 
> SQLite exception!
>
>    } catch(SQLite_Exception $e) {
>
>        echo "problem with query";
>        return;
>    }
> }
>
>
> This has a big knock on effect that we can not lazy load Exception 
> definitions, even if they are only used in Exceptional situations. 
> (its pretty much the same issue as instanceof - forcing the loading of 
> code, that may never be used, except to test it's non-existance.)
>
> Regards
> Alan
>