On 17 January 2015 at 15:43, Andrea Faulds <a...@ajf.me> wrote: > Hi François, > > > On 17 Jan 2015, at 15:37, François Laupretre <franc...@tekwire.net> > wrote: > > > > I would prefer deciding that returning null is the standard way for a > constructor to inform the PHP core that the object creation failed (for any > reason). This would be trapped by the core and cause a catchable fatal > error. > > > > This is more compatible with the 'exception-less' behavior of the core > in general. The constructor is still free to throw an exception but this > wouldn't be encouraged nor the standard way to inform the core that an > error occurred. > > I don’t really agree here. For some reason we have this tradition of not > using exceptions for “procedural” stuff. That sort of makes sense for > functions, but classes are “OOP” and therefore I don’t see a good reason > why they shouldn’t throw exceptions. Exceptions and OOP (and namespaces, > even) should not be the domain of userland exclusively, they are also the > domain of internals/core. If you really hate exceptions, I’d say you should > just use one of those ridiculous “procedural” alternative functions (that > are just methods in disguise) that we went to the bother of adding. > > By the way, it irks me (and many others) that PDO doesn’t throw exceptions > by default. It really ought to, it’s an OOP API, I’d love to see that > changed in PHP 7. > > The difference is that AFAIK all the exceptions returned by OOP extensions right now are of classes specific to that extension, whereas this would be a global engine-thrown exception. We'd have to decide on the class of the exception, its position in a class hierarchy, etc. I'm personally in favour of the core using exceptions more, but only if done properly (I don't like the idea of a single non-semantic EngineException as previously proposed, except as the base class for a proper hierarchy).
I'm also in favour of extension objects behaving more like userland ones, which means that a constructor should either give an instance of the named class or error (if you need something more flexible, build a factory instead). If extensions want to throw their own exceptions from constructors, that's fine, obviously, but it would be more consistent right now if the generic "extension failed to create the right thing" catch issued an error like for other "unexpected condition" scenarios. -- Rowan Collins [IMSoP]
