Hello Adam,

Wednesday, April 14, 2004, 7:36:43 AM, you wrote:

> On Wed, 14 Apr 2004, Marcus Boerger wrote:

> Hello Marcus --

>> > This is actually a pretty nasty side effect of throwing exceptions in
>> > ctors because these two lines have *very* different results if they
>> > fail:
>>
>> > $db = new SQLiteDatabase();
>> > $db = sqlite_open();
>>
>> sqlite_open returns a resource and new SQLiteDatabase returns an object.
>> The latter is a ctor and to prevent it throwing exceptions you'd need to
>> provide a factory method, make the ctor private (which prevents inhering)
>> and then look ofr all possible kinds of failures before calling the ctor.

> I understand the differences between the two. However, I believe that
> most people view these two actions as identical. In their minds, the
> only difference is whether they're using a procedural or OO API to
> create a connection.

> I realize, for current technical reasons, ctors need to throw
> exceptions; however, the end result is that changing from one API to
> another ends up turning a failed database connection from a harmless
> warning to a fatal error.

> This seems bad because it's not an obvious side effect. Additionally,
> given the current anti-exception sentiment on this list, it also seems
> odd to essentially require all object instantiations (but only
> instantiations) to be wrapped inside a try/catch block, or risk an
> immediate script termination.

> Is there anything we can do to preserve the ability to alert
> developers to errors during the construction process without also
> forcing them to catch exceptions?

The way to avoid exceptions in ctors is using empty exceptions and
issuing E_WARNINGs or E_ERRORs from every method when the instance
wansn't initialized already. If you think twise this is worse and
also comes along with a speed penalty from the additional checks.
Anyway if you don't want to deal with exceptions in ctors then you
probably might not want to deal with oo at all.

marcus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to