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

Ernesto Baschny [cron IT] ernst at cron-it.de
Tue Sep 22 11:34:28 CEST 2009


Steffen Kamper schrieb:
> Hi Ernesto,
> 
> Ernesto Baschny [cron IT] schrieb:
>> I was thinking that enabling the "nice new features" is a good start for
>> a newby. A performance-junky will be aware where to "tune".
>>
> 
> 
> Rupi measured 8% performance loss, which is quite a lot, so it's not
> only relevant for "junkies" ;)

Well I just did some profiling why it has so much impact, even on a
cached page. It turns out that the problem comes from the fact that
until now we were supressing "PHP Notices", because TYPO3 core is really
full of "Undefined index".

On a very simple cached page, I get more than 600 calls to
t3lib_error_Errorhandler->handleError() and those are basically all
"Notices" and "Runtime notices", like:

Runtime Notice: Non-static method t3lib_div::getClassName() should not
be called statically
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:4921)
Notice: Undefined index: t3lib/class.t3lib_userauth.php
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_userauth.php:1333)
Notice: Undefined index: tslib/class.tslib_feuserauth.php
(/www/shared/TYPO3core/trunk/typo3/sysext/cms/tslib/class.tslib_feuserauth.php:569)
Notice: Undefined index: pid
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:314)
Notice: Undefined index: FE_SESSION_KEY
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:314)
Notice: Undefined index: t3lib/class.t3lib_userauth.php
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_userauth.php:211)
Notice: Undefined index: t3lib/class.t3lib_userauth.php
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_userauth.php:212)
Notice: Undefined index: HTTP_REFERER
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:3830)
Notice: Undefined index: REMOTE_HOST
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:3830)
Notice: Undefined index: rootLevel
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_userauth.php:829)
Notice: Undefined index: logintype
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:314)
Notice: Undefined index: user
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:314)
Notice: Undefined index: pass
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:314)
Notice: Undefined index: challenge
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:314)
Notice: Undefined index: skipSessionUpdate
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:314)
Notice: Undefined index: rootLevel
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_userauth.php:829)
Notice: Undefined index: t3lib/class.t3lib_userauth.php
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_userauth.php:739)
Notice: Undefined index: t3lib/class.t3lib_userauth.php
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_userauth.php:757)
Notice: Undefined index: makeInstanceService
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:4995)
Notice: Undefined index: ext/openid/sv1/class.tx_openid_sv1.php
(/www/shared/TYPO3core/trunk/typo3/sysext/openid/sv1/class.tx_openid_sv1.php:465)
Runtime Notice: Non-static method t3lib_div::getClassName() should not
be called statically
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:4921)
Notice: Undefined index: tx_openid_mode
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:314)
Notice: Undefined index: tx_sv_auth
(/www/shared/TYPO3core/trunk/t3lib/class.t3lib_div.php:4995)
....

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.

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)


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 have those two new settings:

- exceptionalErrors = list of E_* constants to turn into "exceptions".
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".

- 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'

*** displayError=1 =
=> php's display_errors=1
=> set exceptionalErrors = none
=> set exceptionHandler = 'production'

*** displayError=2 and devIPmask matches
=> php's display_errors=1
=> set exceptionalErrors = E_ALL & ~E_NOTICE
=> set exceptionHandler = 'debug'

*** displayError=2 and devIPmask does not match  (like displayError=1)
=> php's display_errors=0
=> set exceptionalErrors = none
=> set exceptionHandler = 'production'

*** displayError=-1  (which is the default on a new installation)
=> leave php's display_errors alone
=> use default exceptionalErrors (E_ALL & ~E_NOTICE)
=> use default exceptionHandler ('production')

*** NEW displayError=-1 and devIPmask matches
=> leave php's display_errors alone
=> set exceptionalErrors = E_ALL & ~E_NOTICE
=> set exceptionHandler = 'debug'

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.

The last setting new option would make the "displayError" setting almost
irrelevant on new setups, as you simply need to add devIPmask to get
debug output for that IP range.


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?

Cheers,
Ernesto


More information about the TYPO3-team-core mailing list