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

[Rupert Germann]

hi,

here's v6:

- added "return true;" to handle_error() to prevent it falling back to 
PHP internal error handling
- added a param description for the new var $exceptionalErrors in 
constructor of t3lib_error_ErrorHandler

greets
rupert


Rupert Germann schrieb:
> hi,
> 
> after further reading I revoke my +1
> 
> php manual says for function set_error_handler():
> -- 
>  If the function returns FALSE then the normal error handler continues.
> -- 
> 
> we should do this, too.
> 
> concerning the @ singn php-manual says:
> Of particular note is that this [error_reporting] value will be 0 if the 
> statement that caused the error was prepended by the @ error-control 
> operator.
> 
> but then our error handler should not output anything.
> 
> the initialisation of the error handler is a bit weird - should not be 
> done in function setExceptionalErrors()
> 
> I changed this in the attached patch,
> but I've still no idea how about get around that @ problem
> 
> greets
> rupert
> 
> 
> Rupert Germann schrieb:
>> Ernesto Baschny [cron IT] schrieb:
>> ....
>>> Just remove the line that overwrites the exceptionalErrors. The default
>>> is E_ALL&~(E_NOTICE|E_WARNING), which will exclude warnings from the
>>> exception handling, because this might lead to stuff like you noticed.
>>> :)  We are still not "warning-free" in a default TYPO3 installation.
>>
>> just noticed that the warnings from the exceptionhandler ignore @ signs.
>> e.g.: I get a waring when I open a tt_content record for editing:
>>
>> t3lib_error_ErrorHandler::handleError(2, "in_array() [<a 
>> href='function.in-array'>function.in-array</a>]: Wrong datatype for 
>> second argument", 
>> "/srv/SVN/forge.typo3.org/Core/trunk/t3lib/class.t3lib_tceforms.php", 
>> 3769, array)
>>
>> and the mentioned line says:
>>
>> && (!$wConf['enableByTypeConfig'] || 
>> @in_array($wid,$specConf['wizards']['parameters']))
>>
>> I know that there are quite a lot of @ signs more in the core. That 
>> would lead to a unusable BackEnd if someone enables E_WARNING in 
>> exceptionalErrors.
>>
>> Any Ideas what we can do about this?
>>
>> greets
>> rupert
>