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? -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
