Best practices when an unknown error occurs on a dynamic website?

Question

I have a PHP site which (as every other site) has some hidden errors. The question is what should happen when an error occurs?

I see lots of PHP and other sites where in case of an error the page is a bit broken, sometimes even an internal error message is dumped to the page, but usually the site stays partly usable.

The other approach which I follow is to terminate page rendering instantly and show an error message to the user.

Which is the more user friendly approach in your opinion? Let the application continue regardless of the error, so that some part of the page may still be rendered and usable? Or terminate control flow immediately, because it's worse to show a half-baked page to the user and a proper error message should be shown instead?

Update: it's not about 404 pages, rather about those cases, when the page is found, but problems occur during generating it.

Answer 1

I like letting the server handle all 404's and 500, 503 etc... and automatically pointing users to a pretty page with a Oops! message with the site navigation intact so he/she can navigate from there. Also i like adding a go back button (a javascript history.go(-1) : People have mixed feelings about that approach though

if you dnt know how2 add the apache server error re-directs just check out http://onlamp.com/onlamp/2003/02/13/davidsklar.html

Answer 2

Well anyway when an unknown error occurs by definition, it's unknown. So you shouldn't know automatically what to do.

The best way is to display a nice error message (every framework supports to display a specific content when there's an error).

Sending yourself an email so you can track those errors and correct them is, of course something you should also be doing.

Answer 3

PHP differs between messages of the E_ERROR and E_WARNING level (among many others, but those are likely to be the 2 most common). In PHP's default behavior, E_ERROR level errors will stop all further execution of the script, while E_WARNING level warnings will only be thrown before continuing.

As explained in the PHP Manual, this is done with a reason; in general, fatal errors are just that, and you shouldn't attempt to continue script execution, even though that IS possible using custom error handlers. Fatal errors are - hopefully - highly uncommon, but when one does get thrown, I consider it best practice to terminate and display a clear, meaningful error to the user.

Warnings deserve a different approach though; since they're not fatal and don't terminate execution, you should simply log the error, perhaps show a small warning indicating to the user what part of the page can not be displayed properly, and simply continue running your script.

I would suggest though to never show PHP's default error / warning messages to the user. They're unprofessional, ugly, and might give more malicious users insight into your site's database and file structure.

TL;DR version: Stick to PHP's Default behaviour, but always change the error handler to something a bit more sightly.

Edit: I misread part of the question, and didn't really get the 'unknown' part. My answer still stands though; as long as the error isn't fatal (i.e. doesn't completely disrupt the script's flow) there is no reason to halt execution. Errors that do impact the rest of the script (i.e. Database errors that prevent all content from being queried) should be handled as if they were of an E_ERROR level, though.

Answer 4

This is a general question and not just limited to PHP.

You should never show a half-baked page. If a page has an error that would make it unusable to the user (the reason does not matter), you must display an error page. If the page has an error that you've already considered -- like an RSS feed that you can't get -- then go ahead and show the working part of the page.

On the other hand, if there was an error in processing -- again, the reason does not matter -- you indicate that to the user and let them retry.

In Ruby on Rails, we are always ready to redisplay the page after a processing error (including validation problems). If there is a problem rendering, however, an error page would be shown.

This is all common sense, but just remember that 99% of errors are unknown in origin (made up statistic, but basically true) but good software is made to react to those gracefully (from the user perspective).

Answer 5

I quite like Django framework practice to show "Internal Error" page and e-mail backtrace and other debug information back to me. This is probably the best way to make me fix the issue. (Especially when it is not easily reproducible.)