2015-07-31 23:36 GMT+02:00 Yasuo Ohgaki <yohg...@ohgaki.net>: > Hi Niklas, > > On Fri, Jul 31, 2015 at 7:20 PM, Niklas Keller <m...@kelunik.com> wrote: > >> Using set_error_handler isn't handling errors gracefully. Well, it's >> better than E_ERROR, but then libraries can't handle those errors >> gracefully, because the user might override its error handler by setting an >> own handler. > > > Now I see what do you mean by "gracefully". > > TL;DR; > It's app developer jobs to handle these fatal errors. >
Nope. > Most fatal errors shouldn't be recovered by library. e.g. Fallback to non > CSPRNG when CSPRNG is not > available. > They should totally be handled. You need to catch the error and throw a defined exception, otherwise your public API will break if you choose to use another internal implementation. Additionally, you seem to assume that the library doesn't have to do things like cleanups in such a case. Regards, Niklas > IMO, library authors do not have to worry about errors like session's > E_RECOVERABLE_ERROR > or CSPRNG not available. These are fatal errors by its nature and app > developer or system administrator > job to handle them. We cannot blindly assume such fatal errors never > happen in production apps, so we > are better to give users a chance to return "Nice error page/message" when > it happened. > > Anyway, we are better to move errors to exceptions at once and force "all" > modules including 3rd party > module to raise exceptions. i.e. Make php_error_docref() raise exceptions. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net >
