[TYPO3-dev] t3lib_error_Exception

[Ernesto Baschny [cron IT]]

Ernesto Baschny [cron IT] schrieb:
> Rupert Germann schrieb:
>> Steffen Kamper schrieb:
>>> but not *warning* ;)
>>>
>>> 'exceptionalErrors' => E_ALL ^ E_NOTICE
>> which includes E_WARNING - only notices are suppressed.
>>
>> testcase:
>> create a tt_content element text/w image
>> upload an image
>> delete this image from the upload folder
>> open the content lement with the missing image for editing
>>
>> in 4.2 you still had a chance to fix this in the TYPO3 BE
>> in 4.3 you can fix this only in phpmyadmin or in the filesystem
> 
> True, maybe we should return 'false' in case of E_WARNING so that our
> exception handling works as before, but the script continues (as it
> would in regular PHP mode). Wouldn't that be sufficient to keep
> backwards compatibility but still handle warnings through our new scheme
> with a much better reporting?

I must withdraw this suggestion, as this is not possible. Once an
WARNING is turned into an exception, there is no way the PHP code to
continue executing at the point it was before.

So the current solution (not including E_WARNING in exceptionalErrors)
is the best compromise backwards compatibility wise.

But in my eyes we (core developers) should add E_WARNING to see a stack
trace and then go and handle these warnings in place: The example from
Rupi is a classical one which shouldn't generate a PHP warning but
instead a "user warning" but continue operation (so the user can fix the
missing image, for example).

For these kind of warnings (something is wrong, but we "catched" it), we
should probably use flash messages on top of our output. There are also
other situations where you end up having warnings in the BE (broken TCA,
broken table structures, etc...). Would be a nice project to get rid of
all those ugly stuff.

Cheers,
Ernesto