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

Rupert Germann rupi at gmx.li
Fri Sep 25 15:40:19 CEST 2009


hi Ernesto,

great patch. I think now we have all together.
I like the "new" production error message ;-)

besides some CGL nitpicking
+1 by reading and testing

one little usability improvement suggestion: move all error/exception 
related TYPO3_CONF_VARS to each other in "all configuration".
currently "displayErrors" is quite far away from exception handling in 
the configuration form.

greets
rupert




Ernesto Baschny [cron IT] schrieb:
> 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
>>
> 


More information about the TYPO3-team-core mailing list