Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17615
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 8 Aug 2005 19:58:43 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1214163086.20050808195843@marcus-boerger.de>
To: Tobias Schlitt <tobias@schlitt.info>
Cc: Johannes Schlueter <johannes@php.net>, internals@lists.php.net,
	Sebastian Bergmann <sb@sebastian-bergmann.de>
In-Reply-To: <42F75FA0.6090404@schlitt.info>
References: <Pine.LNX.4.62.0508081150140.2940@localhost>
	<dd7fru$tv2$2@sea.gmane.org> <42F7587B.6050901@schlitt.info>
	<200508081450.46458.johannes@php.net> <42F75FA0.6090404@schlitt.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] type hinting throwing a fatal error
From: helly@php.net (Marcus Boerger)

Hello Tobias,

Monday, August 8, 2005, 3:35:28 PM, you wrote:

> Hi Johannes Schlueter!
> On 08/08/05 14:50 you 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.

> The point is, that it's senseless to have it throw any exception that
> can be disabled, when you want to write portable applications. In that
> case you still have to stick to catch Exception and have no benefit of
> it throwing anything else, when SPL is enabled.

> I would pretty much appreciate it having thrown an
> InvalidArgumentException, but then this should work everywhere.

If you plan to support PHP builds without SPL then that most likley means
that you have dropped other built-in default extensions too. Probably
because of their memory space to reduce loading time. In that case you are
not up for portability or have made a major mistake already in the
beginning.

Anyway there is no argument here. If you go for portable apps in the sense
that any extension can be diabled then catching plain Exceptions should be
more than good enough. You cannot expect to have full blown oo support when
you disable the one oo extension.

As a side note we could probably also move all exception declarations from
SPL to the engine but then we'd loose the possibility to support builds
without SPL. At the end of the day i'd even like to drop reflection support
from the engine and move it to a specialized extensions - again - for
speed/memory reasons.

best regards
marcus