[TYPO3-core] RFC #9355: Add an error and exception handler (backported from FLOW3)

Rupert Germann rupi at gmx.li
Tue Sep 22 13:55:33 CEST 2009


Ernesto Baschny [cron IT] schrieb:
...
> Notice that the error handler currently only handles
> "exceptionalErrors", which are E_USER_ERROR and E_RECOVERABLE_ERROR by
> default (see config_default.php). So registering for "every error" and
> afterwards only handling those two makes the performance slowdown. I
> already profiled that.

Thanks for clarifying this, I can confirm that actually each and every 
notice hits the error_handler.
no matter which display_errors setting I have in php.ini

> So I propose (and I will come up with the patch) is to:
> 
> 1) (easy) only register set_error_handler for errors that we want to
> turn into exceptions (thus leaving notices and runtime notices to the
> default PHP handler, which is way faster)

exactly.
that did the trick for me:

set_error_handler(array($this, 'handleError'), ini_get('error_reporting'));

then only "real" errors call the error_handler.
should be way faster than before.

> 2) (needs discussion) Since people seem to like the fact that
> displayError=0 makes all PHP errors just "disappear", this now conflicts
> with the new and more flexible exception handling.

we educated them to like this ;-)
install tool says (displayErrors): "... It is suggested that you set 
this to "0" and enable the "error_log" option in php.ini instead."

> We have those two new settings:
> 
> - exceptionalErrors = list of E_* constants to turn into "exceptions".

exceptionalErrors = array of E_* constants

> Currently defaults to E_USER_ERROR and E_RECOVERABLE_ERROR, should
> default to E_ALL&~E_NOTICE in my eyes so that we don't have mix of "PHP
> error handling" and "TYPO3 error handling".

exceptionalErrors = E_ALL&~E_NOTICE
isn't possible currently. We have to list all errorlevels one by one in 
this array.

> - exceptionHandler = might be "debug" (full stack trace) or "production"
> (only a nice error message with "500" status). For exceptions that are
> not catched, and also for PHP errors that are turned into exceptions by
> exceptionalErrors (see above).
> 
> We could set defaults in the different displayError situations. My
> suggestion:
> 
> *** displayError=0 = no error or exception handling (as we had before).
> => php's display_errors=0
> => set exceptionalErrors = none
> => set exceptionHandler = 'production'

set exceptionHandler = ''
to prevent registering it at all

....
> This is the most backwards compatible setting I can find, enabling nice
> error messages if something is wrong for new users (I find it disturbing
> if a new user installs an buggy extension and gets a "blank page") but
> also considering displayError settings.

I fear that if a user install a buggy extension on a production system 
we can't help him ;-)

...
> 3) (to Ingo): class t3lib_error_Exception extends t3lib_exception but
> t3lib_exception is not found in your patch. Could you submit it to the
> list, too?

strange thing, in the first patch it reads:
class t3lib_error_Exception extends Exception

and if I change it to this it works.
never saw a class t3lib_exception.

greets
rupert





More information about the TYPO3-team-core mailing list