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

[Oliver Hader]

Hi Ernest,

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.

Great & thanks for your work on this.

Here are some remarks:
* E_ALL&~(E_NOTICE|E_WARNING) -> E_ALL ^ E_NOTICE ^ E_WARNING
* E_ALL&~E_NOTICE -> E_ALL ^ E_NOTICE
* Unresolved backported FLOW3 issues:
  + t3lib_error_AbstractExceptionHandler defines with handleException()
but has no functionality - did I miss something
  + t3lib_error_DebugExceptionHandler::echoExceptionWeb() checks against
FLOW3's 'Packages/' in the file path
  + t3lib_error_DebugExceptionHandler::echoExceptionWeb() has a link to
typo3.org/go/exception/... that points to a FLOW3 message - I think we
should comment that out and add a "@todo" until we have own additional
messages there

I suggest that we mark these unused FLOW3 parts with a proper "@todo"
and re-check them later on or remove them completely.

Besides that:
+1 on reading and testing

olly
-- 
Oliver Hader
TYPO3 Release Manager 4.3