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

[Rupert Germann]

Ernesto Baschny [cron IT] schrieb:
> Rupert Germann schrieb:
>> - removed the following files as they are not used/needed:
>> class.t3lib_exception.php
>> class.t3lib_error_error.php
>> class.t3lib_error_exception.php
>> class.t3lib_error_warning.php
> 
> I think this is not correct. The exception handling of TYPO3 should
> provide the proper base classes for future use.

I don't get the point currently. Can you give an example how this would 
look?

  > t3lib_error_error and t3lib_error_warning are probably there so that
> other user-defined exceptions can subclass this. I wonder why these
> don't subclass t3lib_exception? Using them, later the warnings
> exceptions that "noone" catched could go to a log file, error-exceptions
> go to the admin mail, etc.

I'm quite shure that in the current state they are useless.

...
> I would propose even to add echoExceptionCLI and echoExceptionWeb to the
> required methods in interface.t3lib_error_exceptionhandlerinterface.php
> so that all implementations provide those two methods.

done

...
>> - changed the default value to E_ALL ^ E_NOTICE ^ E_WARNING
>> - added some error numbers to the field description of exceptionalErrors
> 
> Which ones? Where? Cannot find it by reading the diff from v4 to v7.

field description of exceptionalErrors in config_default.php:

Integer: The E_* constant that will be handled as an exception by 
t3lib_error_ErrorHandler. Default is "E_ALL ^ E_NOTICE ^ E_WARNING" 
(6133) and "0" if displayError=0. Some values for errors: E_ALL=6143, 
E_ALL ^ E_NOTICE=6135. See php documentation for more details on this 
integer.

..
>> - moved the call to set_error_handler() from contructor to function
>> setExceptionalErrors()
>> - renamed function setExceptionalErrors() to
>> setErrorHandlerForExceptionalErrors()
> 
> Ok, but I would keep setExceptionalErrors. This is already in the class
> that is supposed to handle errors, this doesn't need to be announced in
> the method name again. So I would opt for the shorter name (from FLOW3).

I'm for the longer name ;-)

I made a patch v8 from this changes.

greets
rupert