[TYPO3-dev] t3lib_error_Exception

[Ernesto Baschny [cron IT]]

Steffen Gebert schrieb:

> I have a problem with the new error and exception handling.
> 
> EXT:phpmyadmin always causes a warning instead of the login prompt:
> Warning: ob_start() [ref.outcontrol]: output handler 'ob_gzhandler'
> cannot be used after 'URL-Rewriter' in
> /kunden/220702_81827/webseiten/fw-devel-4.3/typo3_src/typo3/init.php
> line 435
> 
> This was no problem before, but now TYPO3 dies with typo3PrintError()
> (with displayErrors != 2). While the site was usable before, it now
> isn't. Is this what we really want (to die on every PHP warning)?
> 
> I'm a bit unhappy with the ProductionErrorHandler (I know, there were
> already so many discussions), but why has a user-(=visitor)-friendly
> error message a title "t3lib_error_Exception" and as text the raw PHP
> warning text. I'd expect
> 
>    "We're sorry, but our page is currently not available"
> 
> or sth. like this. So we get back to times, when TYPO3 outputted only
> geek-understandable words (using default settings).

Hm, we have never had "these times", as before TYPO3 would only output a
blank page in these situations. So if you think this is more user
friendly, I guess you are the "geek". :)

But anyhow, of course the current error output is just the start. The
cosmetics (and usage) of the exception handling will have to be worked
out now that we have the basic functionality "in". This is why it is
important to have in our beta so that we can make it look "good" until
the release.

> What I really like is, how easy it should be to extend
> ProductionErrorHandler with an own one styled in corporate design, but
> I'm unhappy with the default :(
> 
> Are there concrete plans to refurbish the typo3PrintError() stuff for
> 4.3 or what's your opinion of a user-friendly error handler?
> 
> What do you consider the appropriate setting for displayErrors in
> production context? What happens with value 0? Is there a blank page in
> case of an Exception? So if we have an ProductionErrorHandler, I'd say
> we should use it to give an explanation/excuse and not hide all its
> warnings.

displayError will behave "as before", in that in production mode
(displayError=0) no PHP warnings / errors are outputted (they are not
handled at all by the new handler) and only in "development mode"
(displayErrors=1 or =2 +devIPmask set and matching) you will get all
errors / warnings with new stack traces.

Cheers,
Ernesto