On Fri, Aug 3, 2012 at 4:19 PM, Stan Vass <sv_for...@fmethod.com> wrote:
> Hi all, >> >> Can anyone explain to me the reason that when a function or class is >> disabled via the ini setting, an attempt to access the disabled item >> generates a non-fatal error? >> >> I'm looking at a segfault in the SPL caused by the blind creation of a >> class, which seems to only fail when the class is disabled. I'm >> wondering in how many other places this could occur. >> >> The obvious solution is to be more careful and check return values, >> but a FATAL would also have prevented execution continuing. >> >> Thanks, >> >> Leigh. >> > > PHP has a long history of issuing errors of the wrong type at the wrong > time. My experience shows it's best to have an error handler convert all > errors to catchable exceptions, with some error types (like E_STRICT, > E_ERROR etc.) to become instant fatal errors (can't be caught). > > This would also solve your use case since the warning will become an > exception with a stack trace clearly pointing to the origin of your > problem. Additionally you can handle an exception on a higher level in the > stack once instead of doing it for every function/class call. > > I'm afraid fixing the default behavior is a big hopeless since it'll break > BC and require a major rethinking of the way PHP issues errors. > > See: set_error_handler(). > > a php function/operation can raise more than one warning, how would you handle that? with exceptions you would only get the first one. another issue is that with the current error handling model a call can trigger a non-fatal error and still return some data. with exeptions you can't do that. so changing our internal error handling isn't as easy to start throwing ErrorException-s, it would require much more workthan that. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
