On 18 January 2015 at 11:28, Tony Marston <tonymars...@hotmail.com> wrote:
> "Andrea Faulds" wrote in message news:23490588-0131-4B0F-A7AA- > c9c8c7666...@ajf.me... > >> >> 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. >> > > You are forgetting one minor thing - an object may be instantiated from a > piece of procedural code. In fact the very first object can only be > instantiated from procedural code. I'm not sure what you mean by the second sentence here; which is the "very first object"? > The idea that every piece of code that uses "new" will have to be amended > to be in a try...catch block is a huge amount of work that does not solve > any problem (except to satisfy the delicate sensibilities of the OO > purists). Bear in mind that there are costs to users writing new code as well as costs to those maintaining existing ones. When writing code from scratch, it's actually much easier to write code with catch/finally than to check for non-object returns before using every object. The errors for uncaught exceptions are generally much easier for a new user to understand than the errors for accessing a method on what turns out to be a null value not an object. > > > 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. >> > > If you really want a clever way of introducing exceptions into PHP without > breaking huge amounts of existing code then how about this idea - change > the language to detect if a function/method is being called within a > try...catch block or not. If it is then throw an exception, but if it is > not then use the old error handler. In this way the use of exceptions would > not be forced on the developer and existing code would not break. This > would me more work for the core developers, but no broken code in userland. > > Unfortunately, that wouldn't be as useful as it sounds. Consider this code: try { somefunc($foo); } catch ( InvalidArgumentException $e ) { ... } If somefunc() internally uses PDO, should it automatically switch to exception-throwing mode, because a try-block is in the stack? Or should it hunt in advance for matching catch() clauses, which would probably be extremely slow? And if the user lazily writes catch(Exception $e) around a top-level function, suddenly their whole application behaves differently, because their inline error handling suddenly stops working? Unfortunately, exceptions require a specific way of thinking, at least in the area of code where they occur, because they don't neatly reduce to equivalent linear code. -- Rowan Collins [IMSoP]
