RE: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
> From: Ferenc Kovacs [mailto:[email protected]]
> Sent: Wednesday, February 22, 2012 3:55 PM
> To: John Crenshaw
> Cc: Peter Lind; Larry Garfield; [email protected]
> 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.
Thread (18 messages)