NYCPHP Meetup

[Michael Sims]

On Tuesday 17 February 2009, David Krings wrote:

> Working now in QA and having had years of experience with support you do
> want to report exactly what went wrong and what the user can do about it
> (if possible).  Implementing useless error messages is just bad advice
> and makes for bad software. Make your PHP script determine what went
> wrong and show a useful error message. At a minimum an error message must
> include: - type of error
> - reason for error
> - what was received (if applicable)
> - what was expected (if applicable)
> - measures to prevent or workaround error or instructions to obtain
> additional help (such as "Read the applicable error description in the
> help here: <link to help topic>" or "Contact support at
> blahblah at blah.blah"). Ideally, provide a solution right then and there.
>
> Optionally report this:
> - the name of the module / script in which the error occured
> - additional information such as server and PHP version or custom error
> codes

You should read my prior message again, as you haven't understood it.

The user can't work around a PHP fatal error in an Ajax call.  Knowing the 
module that broke is nothing but confusing for the user.  No major website 
implements the procedures you describe.

Here's Gmail's errors:

http://mail.google.com/support/bin/static.py?page=error_msg.cs

Note that all of the serious errors - something actually broken - are things 
like "Oops" and "Temporary Error 502" and "We're experiencing technical 
difficulties that may prevent your chats from being sent".  There's 
absolutely nothing in there about a crash in module someRandomGmailModule on 
line 972.

If the error is truly due to something under the user's control ("cookies 
not enabled"), there's a good case for telling the user that.  But there's 
nothing the user can do with a PHP script that throws a fatal error.

The words "Something seems to be wrong" are my shorthand for a short error 
message to the user indicating a problem.  In general, it is totally useless 
and massively counterproductive and often presents security problems to give 
the user internal details of the error.  Probably the number 1 source of XSS 
vulnerabilities is echoing user-submitted data back in error pages.

Certainly the PHP script which blew a gasket ought to log something to the 
system log files, trying its best to tell the maintainers what went wrong 
and how.  But exposing those messages to the users is terrible practice.  
Nor is it even possible, since the Javascript call *by definition* won't get 
much useful from a PHP page where a fatal error occurred - whatever useful 
information there is must be logged by the PHP script itself.


Michael Sims

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20090217/e9906f6e/attachment.html>