[TYPO3-core] RFC #9355: Add an error and exception handler (backported from FLOW3)
Ingo Renner
ingo at typo3.org
Tue Sep 8 10:34:39 CEST 2009
Rupert Germann wrote:
Hi Rupert,
> the array of errorlevels should only contain that errors that can
> actually reach handleError().
do they contain others? I didn't lok up the values and trust that Robert
& Co chose them wisely already... If they should be changed, make a
recomendation to which values they should be changed please, I'll adopt
that then.
>> Then there are two different exception handler, one for production,
>> and one for debugging / development.
>> The debug exception handler shows a nice backtrace of the exception.
>> The production exception handler only displays a message that
>> something went wrong.
>
> I don't get the point why we would need a "production exception
> handler". we always recommanded to completely disable the display of php
> errors/exeptions for production sites.
Did you actually test it? I don't see an error/exception - at least in
the way pure PHP would show them - which IMO is the purpose of the
exception handling.
Apart from that, please remember that these handlers are the last resort
for exceptions, in general exceptions hsould be handled using
try/catch() blocks. So the exception handler is just a "safety net" for
cases where exceptions are not properly handled by application logic.
> The initialisation for both handlers is done directly in index_ts.php
> and init.php. That means it will slow down FE and BE of all sites.
If you can come up with a better way, I'd be interested.
> I'd like to see a possibility to disable error and exception handling
> completely, which is not possible atm.
I'd rather not provide such an option, the exception handling is there
for a purpose at least.
> now to some functional thingies:
> display errors is enabled in php.ini
> localconf:
> $TYPO3_CONF_VARS['SYS']['devIPmask'] = '*';
> $TYPO3_CONF_VARS['SYS']['displayErrors'] = '1';
even if display errors isn't enabled in php.ini,
['SYS']['displayErrors'] = 1 would enable it. I'd recommend the "2"
setting though, which takes into account your devIPmask.
> means: we use t3lib_error_DebugExceptionHandler
right, but why would you do this?
> on my system I see an output from the exceptionhandler only in the
> following 2 cases:
>
> trigger_error('E_USER_ERROR', E_USER_ERROR);
> throw new Exception('ExceptionException',23);
>
> all other tests result in no output or
> Fatal error: Cannot redeclare strpos() ...
> Parse error: syntax error, unexpected ...
> Fatal error: Wrong parameters for Exception(...
as you already stated yourself, the exception handler can't handle fatal
errors. If there's no output, I'd say this is a result of the set
error_reporting level atop of init.php and index_ts.php.
all the best
Ingo
--
Ingo Renner
TYPO3 Core Developer, Release Manager TYPO3 4.2
More information about the TYPO3-team-core
mailing list