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

Ernesto Baschny [cron IT] ernst at cron-it.de
Fri Sep 25 15:44:27 CEST 2009


Hi,

Rupert Germann schrieb:

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

Nice idea. The order is simply the order found in the array, right? If
so, I will then just move it up to right after displayErrors before
commiting. Ok?

Or Ingo, if you prefer, you can also commit, after all it is your RFC.
Please give us some feedback on your thoughts. I also would love to see
Oli's comment on this, as this is on the roadmap for his release. :)

Cheers,
Ernesto

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