Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12527
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20040901133727.91622.qmail@pb1.pair.com>
To: internals@lists.php.net
References: <4135C8C3.5000705@akbkhome.com> <4135CD4B.6040508@akbkhome.com>
Date: Wed, 1 Sep 2004 15:36:49 +0200
Lines: 54
Subject: Re: [PHP-DEV] parse errors when testing for undefined exceptions
From: r.korving@xit.nl ("Ron Korving")

Okay, I agree with you on this one.
Very weird behaviour by the way.. I didn't know about this.

"Alan Knowles" <alan@akbkhome.com> schreef in bericht
news:4135CD4B.6040508@akbkhome.com...
> 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
> >