> From: Ferenc Kovacs [mailto:tyr...@gmail.com] > Sent: Wednesday, February 22, 2012 3:55 PM > To: John Crenshaw > Cc: Peter Lind; Larry Garfield; internals@lists.php.net > Subject: Re: [PHP-DEV] Exceptions for method on non-object rather than fatal > (desired feature?) > > 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. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu
I didn't forget about OOM and other truly fatal errors. I actually considered mentioning it but decided that specific details should be ignored unless/until people decided they wanted to discuss it at that level. While there are some truly fatal problems (such as OOM), most "fatal" problems are really recoverable if you are allowed to unwind the stack to a known stable point (which is exactly what you get when you catch an exception). A good example would be E_PARSE; no amount of willingness to continue can allow the parser to recover or allow the problem file to execute, but if an exception were thrown and caught up the stack (<cough>autoloaders</cough>), it would be possible to continue from there. (null)->foo() and other critical logic failures fall into the same category; it isn't safe to continue linearly, but you can unwind the stack. Based on my experience truly fatal problems are horribly rare. Probably around 99% of the "fatal" errors I see on a regular basis would have been recoverable using exceptions. John Crenshaw Priacta, Inc.
