Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17596
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,
	tobias@schlitt.info
Date: Mon, 8 Aug 2005 14:50:46 +0200
User-Agent: KMail/1.8
Cc: Sebastian Bergmann <sb@sebastian-bergmann.de>
References: <Pine.LNX.4.62.0508081150140.2940@localhost> <dd7fru$tv2$2@sea.gmane.org> <42F7587B.6050901@schlitt.info>
In-Reply-To: <42F7587B.6050901@schlitt.info>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200508081450.46458.johannes@php.net>
Subject: Re: [PHP-DEV] type hinting throwing a fatal error
From: johannes@php.net (Johannes Schlueter)

Hi Toby,

On Monday 08 August 2005 15:04, Tobias Schlitt wrote:
> >  The throw an Exception when SPL disabled and an InvalidArgumentException
> >  when it is enabled.
>
> That's senseless when writing applications that shall be version
> independant. Just sticking to Exception should be fine.

No it is not, in your application you can still simply catch Exception to be 
independent of SPL since the InvalidArgumentException class extends the 
Exception class. But by using nested Exceptions you can catch them 
independently. Else you would have to catch every Exception, parse the error 
message or trace to see wether it was a problem while calling the 
function/method or some code inside the function/method went wrong.

<?php
function foo() {
    $bar = ....;
    try {
        call_with_wrong_parameter($bar);
    } catch (InvalidArgumentException $e) {
        // bad function call...
    }
}

try {
    foo();
} catch (Exception $e) {
    // any other exception
}
?>


I'd like to see something like what Sebastian suggested. And imho it wouldn't 
really be a bc-break since an uncaught exception is fatal, too.

johannes