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

[Rupert Germann]

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