[TYPO3-dev] output ends up in white page

[Jigal van Hemert]

bernd wilke wrote:
> on Fri, 12 Sep 2008 12:59:02 +0200, Steffen Kamper wrote:
>> this is a wellknown situation, but many users don't know what to do if
>> they end up in white page.
(...)
>> Further we could enhance the error handling. This was discussed in some
>> threads. May be with displayErrors=0 the errors could be fetched and the
>> standard TYPO3-errorbox cold tell that there occured a php error so the
>> page could not be displayed, enable displayErrors to see more details.
> 
> I doubt that you can catch all php-errors and present an error-page.
> most blank pages are php-errors, so no TYPO3 output can be done at the 
> end.

You can't catch *all* errors (e.g. out of memory :-) ), but the ones you 
can catch could be logged with enough information for an admin/developer 
to do something with.

> I think blank page is ok for a normal visitor (instead of hints about 
> errors in configuration), but normaly an unexperienced TYPO3-admin 
> doesn't know what to do and asks in forums.

Blank pages are never okay. People expect response from a website and 
even a decent looking error message (without technical information) is 
better than a white page.

> maybe it would be helpfull to automaticly increase php-errorlogging on 
> screen while a BE-User is logged in.
> as the logging can be configured in install-tool it should be possible to 
> increase it on BE-login. at least if the BE-user has admin-level.

There is a big problem with increasing error report details only when an 
admin asks for it: an error often only occurs in specific circumstances. 
  Not knowing the circumstances makes tracking down the cause of the 
error very complicated.

What can I do with an error like: Warning: mysql_fetch_assoc(): supplied 
argument is not a valid MySQL result resource in <path>/<file>.php on 
line <line> ?
I do no know the query that was involved, I do not know where the 
request originated from (debug trace), I do not know the 
URL/parameters/user/session data, etc.

I would love to have a detailed error log which may be limited in size 
(max. 1000 errors, 100 errors, configurable?). Emails of errors can be 
very handy in certain situations. Maybe emails optional, with 
configurable minimum error level and configurable minimal time interval 
between two error emails? (Default: email on, only pretty severe errors 
(no warnings), minimal 1 hour interval?)

A nice BE tool to view the error log, click to view file/line of code, 
links to PHP/MySQL site, etc. would be great. Also a big help for 
developers BTW!


-- 
Jigal van Hemert.