Closed silverstripe-issues closed 10 years ago
comment by: @halkyon (sharvey) created at: 2012-03-26
E_STRICT and E_DEPRECATED are disabled in the framework because there are strict guidelines that need to be resolved first.
Sam has opened a pull request for E_USER_DEPRECATED here: https://github.com/silverstripe/sapphire/pull/267
comment by: @sminnee (sminnee) created at: 2012-04-18
We should still catch E_RECOVERABLE_ERROR
comment by: @halkyon (sharvey) created at: 2012-04-18
Do we catch that and handle it as a notice just like E_STRICT and E_DEPRECATED for the moment? Edit: just read "catchable fatal error"... so yeah, probably not a notice ;-)
This is being worked on with #2951
And fixed.
created by: paradigmincarnate created at: 2010-11-16 original ticket: http://open.silverstripe.org/ticket/6194
Silverstripe registers a generic error handling function.
The function handles some, but not all of the potential errors. The function also doesn't correctly handle suppression of errors using "@".
There are some php error type which aren't handled in the generic error handler.
Refer to the php manual for all available [http://nz.php.net/manual/en/errorfunc.constants.php error handling constants]
In particular I think E_STRING, E_DEPRECATED, E_USER_DEPRACATED, and most importantly E_RECOVERABLE_ERROR should be handled.
Given that it may not be practical to keep up with all constants as they're added, unknown error types should be handled/displayed.
Php allows all errors for a statement to be suppressed by preceding the statement with the "@" character.
When using a custom error handler such as that in Silverstripe, this must be explicitly handled.
This is usually done by testing/getting error_reporting() within the error handler. If the "@" symbol was used, and thus errors suppressed, error_reporting() temporarily returns 0 within the scope of the suppressed statement.