Do you bother to write a pretty error page?

Question

So, everyone is really used to the errors that PHP gives you. They look kind of like this:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 2 bytes) in /path/to/file(437) on line 21

My question is, do you put in the time to make your error pages more useful?

I find that I am able to debug a lot faster using my own error page:

I find this to be a lot better than the PHP errors because it gives me a stack trace, the usual error message, along with the actual location of the error, and more.

Also, are there any downsides from creating your own development error pages. Obviously you wouldn't want to have a user see this page, but what about during development?

Edit: Updated the picture to show that the page can expand each Stacktrace element to show its properties. I really like it :)

Answer 1

Like you said, this kind of page can be useful in development, and should not ever appear on a production server.

While developping, I generally use the Xdebug extension : it's not hard to install, and provides stacktraces in cases of an error -- which is a lot nicer than the default error messages.

The only thing Xdebug doesn't do, compared to your example, is display the code ; but, when I'm developping, the code in my IDE is generally not far, so I don't think it's a problem not having it in the browser.

After that, if the stacktrace is not enough, I can always re-load the page, using Xdebug + IDE (Eclipse PDT, or netbeans) to de step-by-step debugging, in a graphical environment.

Answer 2

I do not have my own customized error message but I think creating your own error pages during development has more advantages than disadvantages, if there are any (personally, I cannot see one.).

For instance yours in particular, allows the error messages to be more organized where code is actually shown not just referenced by a line number and it definitely adds a nice visual touch than the ordinary PHP error messages.

Also, if you're the only one who's going to see it, why not customize it.

Answer 3

I'd take a page from ASP.NET and you could setup the following:

• If you are viewing the page on localhost, use your custom error page
• If you are viewing outside the localhost, show the user a nice error page (Opps something went wrong, try again or email us, etc. etc.)

Answer 4

I find a stack trace useful. I use Zend's MVC libraries frequently, and the 'default' error (for a development environment) has a stack trace. (Note: I'm referring to the error controller/view generated by Zend's command line tool.) In addition it dumps a list of parameters the controller was passed (essentially the request variables)

Xdebug also replaces 'normal' errors with a more informative stack trace.

So no, I don't take the time to write custom error pages, but I use existing tools accomplish something similar.

About displaying errors for users - I like what Zend does by using an environment flag (easy to set in .htaccess) to determine development/production environment. Development environment gets the stack track, production environment doesn't. Of course the error handler is just another controller/view, so it can be customized however much you want.

Answer 5

In development I do try to make them pretty, I usually try to make it very verbose, and also, I throw in things like:

<?php 
     echo "<pre>";
     print_r($_REQUEST);
     echo "<br />";
     print_r($_SESSION);
?>

at the bottom so I can inspect my session variables and GET/POSTS that were sent. I also like to echo out SQL statments to see how they look once prepared. It depends on what kind of error I'm expecting out of it.

And as others have said, you want none of this in production. I supress all errors and output for production purposes, you can set a set a constant that flags development or production so you only have to change that one flag to disable all output.

Hope this helps.

Answer 6

Leaving stacktrace and revealing error output to the public is a security risk. A black hat can purposely prod your code for weaknesses and learn about your directory structure.

I usually only show error messages if I'm logged in as a developer-level user. Otherwise I'll show a generic message in a generic error template (the point is to leave navigation on the page so you don't break the user's flow).

If the error is a fatal, write it to an error log file so you can analyze wheat users are doing and fix the most common errors first.

Answer 7

Im considering to include in my framework this 3rd party or build an exception handler based on it => http://kaloyan.info/krumo/ maybe you ll like it too, i found it pretty slick and nifty, and a lot of information fits well in only little space

edit :

i forgot, when you go in a production site, the best way is to log errors and display only 500 pages.

function ex_handler($exc){
   ob_clean();
   error_log($exc->getMessage());
   ob_start();
   include_once(TPL.'err500.php');
   echo ob_get_clean();
}
set_exception_handler($ex_handler);

Or something similar