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

[Ernesto Baschny [cron IT]]

Rupert Germann schrieb:

>> So I propose (and I will come up with the patch) is to:
>>
>> 1) (easy) only register set_error_handler for errors that we want to
>> turn into exceptions (thus leaving notices and runtime notices to the
>> default PHP handler, which is way faster)

> exactly.
> that did the trick for me:
> 
> set_error_handler(array($this, 'handleError'), ini_get('error_reporting'));
> 
> then only "real" errors call the error_handler.
> should be way faster than before.

I would simply use the list of errors configured in "exceptionalErrors",
because those are the ones that will get handled. As I said, this will
follow in my patch, as soon as the 2) discussion finds some "agreement":


>> 2) (needs discussion) Since people seem to like the fact that
>> displayError=0 makes all PHP errors just "disappear", this now conflicts
>> with the new and more flexible exception handling.
> 
> we educated them to like this ;-)
> install tool says (displayErrors): "... It is suggested that you set
> this to "0" and enable the "error_log" option in php.ini instead."

True, but the default is still "-1", which means "use PHP settings". The
"0" is nice, but most people don't know how to configure PHP to do
something useful in the background, or don't even have the "power" to do
so (hosting environment). So I think switching over to having this
handled by TYPO3 through Exception handling is much cleaner. An
extension could later be born as a "handler" which mails the user the
stuff using the scheduler, or displays the "last errors" in the Reports
module. I think the possibilities are much nicer (and easier for an
user, as soon as we have proper extensions) than having displayError=0.


>> We have those two new settings:
>>
>> - exceptionalErrors = list of E_* constants to turn into "exceptions".
> 
> exceptionalErrors = array of E_* constants
>
>> Currently defaults to E_USER_ERROR and E_RECOVERABLE_ERROR, should
>> default to E_ALL&~E_NOTICE in my eyes so that we don't have mix of "PHP
>> error handling" and "TYPO3 error handling".
> 
> exceptionalErrors = E_ALL&~E_NOTICE
> isn't possible currently. We have to list all errorlevels one by one in
> this array.

I changed that to be an integer in my patch already. I want
E_ALL&~E_NOTICE, and maybe other combinations. The "array" doesn't add
any information and doesn't allow me to use the same syntax we know
already from other PHP settings.

So I hope that would be "ok" for a change, even if in FLOW3 it is still
an array. Maybe it could be changed in FLOW3 too? Karsten? FYI it is
about the "errorHandler::setExceptionalErrors" method, which in FLOW3
expects an array. I would change that to an integer.


>> - exceptionHandler = might be "debug" (full stack trace) or "production"
>> (only a nice error message with "500" status). For exceptions that are
>> not catched, and also for PHP errors that are turned into exceptions by
>> exceptionalErrors (see above).
>>
>> We could set defaults in the different displayError situations. My
>> suggestion:
>>
>> *** displayError=0 = no error or exception handling (as we had before).
>> => php's display_errors=0
>> => set exceptionalErrors = none
>> => set exceptionHandler = 'production'
> 
> set exceptionHandler = ''
> to prevent registering it at all

Since we have no real performance penalty anymore (because
exceptionalErrors = none means no PHP-errors will turn into exceptions),
I would rather keep it as a defailt of "production". An extension
developer might add exceptions to his code which he wants to have
outputted even in production mode. I am tired of having TYPO3 output a
"blank page" if there is an error, even in on a "live server". All other
CMSs or Webservers output some meaningful error + header-data.

It won't change anything in your output if you don't use exceptions.

> .....
>> This is the most backwards compatible setting I can find, enabling nice
>> error messages if something is wrong for new users (I find it disturbing
>> if a new user installs an buggy extension and gets a "blank page") but
>> also considering displayError settings.
> 
> I fear that if a user install a buggy extension on a production system
> we can't help him ;-)

Of course we can, we can print out some meaningful error, this is what I
mean above. A blank page hardly helps the user in this situation! An
error message means "ok, at least TYPO3 is running, so the webserver is
ok, but I've got an error XYZ". Else the user doesn't even know if
apache is running, or his proxy is doing something bad or even if his
client is buggy.


> ....
>> 3) (to Ingo): class t3lib_error_Exception extends t3lib_exception but
>> t3lib_exception is not found in your patch. Could you submit it to the
>> list, too?
> 
> strange thing, in the first patch it reads:
> class t3lib_error_Exception extends Exception
> 
> and if I change it to this it works.
> never saw a class t3lib_exception.

I just added it, as I found it in the FLOW3 package. It is just an empty
exception class inheriting from PHP's "Exception".

Cheers,
Ernesto