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

Ernesto Baschny [cron IT] ernst at cron-it.de
Thu Sep 24 12:34:34 CEST 2009


Hi Ingo et all,

so I took some time to implement my modifications to this nice feature.

The issues addressed by these changes are:

1) performance problems: solved, so we can always enable it by default.

2) handling of displayErrors and devIPmask: solved more or less in a way
I proposed in my post from 22.9. Meaning backwards compatibility, but a
nice new default for new installations.

3) $TYPO3_CONF_VARS['SYS']['exceptionalErrors'] is now an integer, which
is by default E_ALL&~(E_NOTICE|E_WARNING) (such things cannot be done
with arrays).

4) Remove the hardcoded error-template from FLOW3 and changed it to a
call to t3lib_timeTrack::debug_typo3PrintError, where we have our
"customizeable" error output (which can be changed with a hook already).

5) Use $TYPO3_CONF_VARS['SC_OPTIONS']['errors'] for storing the "to be
used" values (depending on displayError and devIPmask setting) instead
of modifying the original $TYPO3_CONF_VARS['SYS']['exceptionHandler'],
because modifying it in config_default makes it impossible to see "real"
value that is set in the "All configuration" part of the install tool.

6) added the missing t3lib_exception

7) no "@" before the set_exception_handler in debugexceptionhandler

8) fixed broken utf8 chars in debugexceptionhandler::getBacktraceCode

To feel the difference of Ingo's v2 and my v4, I also attached a patch
between those two stages (9355v4-diffto-v2.diff). And then the "full
patch" for the full review (9355v4.diff).

Notice that some changes were done to the auto-backported stuff Ingo
brought us from FLOW3, most of all the change of array=>integer
parameter in exceptionalErrors and also the removal of the
FLOW3-template. While this can be considered "bad", as we can no longer
"auto-backport" the feature anymore from FLOW3, I don't consider this
such a problem, as this will probably end up growing in a different
direction anyway. So I would rather prefer the FLOW3 folks to keep an
eye on TYPO3v4 changes on that part to see if anything interesting can
be adapted on their side.

Cheers,
Ernesto

Ingo Renner schrieb:

> Type: feature
> 
> Bugtracker references:
> http://bugs.typo3.org/view.php?id=9355
> 
> Branches: trunk
> 
> Problem:
> Although we we use exceptions now, we do not have an exception handler yet.
> 
> Solution:
> FLOW3 offers a quite nice exception handler that is easy to adopt for
> TYPO3 4.x. The attached patch introduces a backport of that error and
> exception handling system.
> 
> Notes, how it works:
> First, there is an error handler that transforms errors into exceptions
> Then there are two different exception handler, one for production, and
> one for debugging / development.
> The debug exception handler shows a nice backtrace of the exception. The
> production exception handler only displays a message that something went
> wrong. Both handlers provide a link to typo3.org to look up details on
> what went wrong.
> Whether the debug exception handler is chosen depends on your setting of
> SYS.displayErrors (set to "2" it will also show you the debug backtrace
> when coming from the devIPmask, but to nobody else).
> 
> 
> 
> all the best
> Ingo
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 9355v4-diffto-v2.diff
Url: http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20090924/77b2daf0/attachment-0002.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 9355v4.diff
Url: http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20090924/77b2daf0/attachment-0003.txt 


More information about the TYPO3-team-core mailing list