> > > I've been following this discussion pretty closely and it seems to me that > all the arguments in favor of adding this are actually good arguments for > converting ALL fatal errors to exceptions. I see no compelling reason to > change just this one type of error to an exception, and in fact, changing > just this one error feels awkward and kludgey so I wouldn't really support > that. Even Peter's recent objection (Law of Demeter) mostly derives > strength from the fact that this is a one off change. If all fatal errors > were replaced with exceptions there would be plenty of perfectly valid use > cases that don't break encapsulation. > > There was an RFC for replacing "errors" with exceptions a while back, but > it was a disaster (didn't even cover the (fatal) error cases, wanted to > replace all warnings with exceptions, focused on things that were already > recoverable, etc.) It was the wrong solution to the wrong problem. I don't > want anything I say here to be confused with that. > > I think I do like the idea of (optionally?) replacing fatal errors with > exceptions, but only if it is a general paradigm change. If you are only > going to replace one error, then I don't like the idea because it is > inconsistent and makes core changes to support one person's use case > without considering what the overall need really is. >
don't forget that we can't replace all fatals with exception, because by design fatal errors are used when "errors that can not be recovered from, such as a memory allocation problem". I agree that we tend to raise fatals in some/many cases where E_RECOVERABLE_ERROR or throwing exception would be more appropriate. for those(not you) who think that every notice/warning/error could be turned into exceptions, I would like to repeat something that was mentioned every time when this topic is brought up: - a single php expression/call can raise multiple warnings/notices/errors what would happen those if we would want to turn those into exceptions? - currently there are many functions/extensions where a notice/warning is issued to raise the developers attention about a potential problem, but that doesn't stop the code execution (except if you have an error handler and explicitly aborts the execution), and the call will return the expected result. if those warnings/notices would be turned to exceptions, how could you fetch the return value of that expression/call? to reply to the original proposal which started the thread: I think that the example is lazy and error-prone code, if you can't guarantee the return value of your method calls, you shouldn't chain those. adding another "magic" to php for people being able to write sloppy code easier doesn't really cut it for me. On the other hand I can agree that it would be more OOPis, if calling a non-existent method on an __object__ could throw an exception (MissingMethodException or MethodNotFoundException). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
