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

[Ernesto Baschny [cron IT]]

Hi Rupi,

thanks for taking over. My comments:

Rupert Germann schrieb:

> 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

I don't like that solution. Why do we then need a setExceptionalErrors()
method then? If we call this later, this is never really applied, as it
won't change the errors PHP handles as exception.

So I prefer my previous solution in that the error handler class itself
does nothing on contruct and only if someone instructs it to handle
errors (calling "setExceptionalErrors()") the error handler is put into
place. Which means the error_handling can also be turned off on demand
(by calling setExceptionalErrors(0) on the that object).

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

Exactly. The solution is much simpler than expected: add to the top of
handleError():

	if (error_reporting()==0) { return FALSE; }

meaning the error that PHP has the instruction not to output anything
(prepended by "@") won't also be handled by our handler.

After having this, we could also add E_WARNING to the list of default
errors to handle, as it will then just handle warnings that we are not
currently "ignoring".

Cheers,
Ernesto



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


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