On 03/08/12 16:50, Ferenc Kovacs wrote:
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.
Warnings are special, they aren't really errors as such. They wouldn't
become exceptions.
Also, why should an erroring function return a value?
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
