Breaking down everything on a single error, or just break down that part? [closed]

Question

In PHP, if a module of your site has a problem, you can turn off error messages, so that only that module won't be displayed. This means for example, if you have a weblog based on PHP, and archive module has a problem, then you can still use website, without seeing archive section.

However, in ASP.NET, the smallest error, results in the breakdown of the whole system, unless you put a silent try...catch block.

Which is better from the user viewpoint?

Answer 1

The nature of PHP and ASP are the reasons for your the difference in error handling behavior; they're features of the language and not explicitly designed for end-user reasons. However it's important to note that all the most web technologies have high levels of fault tolerance built in--HTML, Javascript and PHP can chug along despite major errors allowing you to render a page as it's most likely meant to be or render all unbroken parts.

A good reason for this is modern websites are generally very modular, and in addition unlike compiled programs they can't be 100% guaranteed to work perfectly in all regards; if you expect them to you're going to cause a bad user experience because let's face it, you didn't test your site in every possible version of Internet Explorer, Opera, Chrome, Firefox, Safari, ect.

Technical details out of the way, why on earth would you want the whole system to fail on one error? It's not user friendly to give a blank page with just an error message, period. If you can give the user most of the content that's not broken, do it. If most of the content is broken, tell the user why and present any and all of the site not affected by the error as it should be.

Youtube handles this situation very well; on occasion the Subscription, Commenting or Uploading features are temporarily down. Most users aren't using those features at any given time, and it's easy to continue "normal" use of the site without them, and you get a nice error message saying "Calm down, your commenting feature will be back soon" which allows users to know what the problem is and that it will be fixed. How could you even consider taking down all of Youtube because a user can't leave a comment?

Odds are much of your site aren't even tied intimately programming, they're links to other pages with content. As long as that works, leave it in! If it's a web app and the whole site is non-functional, let the user know this. Twitter's Fail Whale is a good example of this; when it's over capacity, Twitter simply won't work, so they have to give you this message.

However they can still serve links like "Help About" ect. There's never an excuse to give a raw Error 500, unexpected condition error message.

Answer 2

This mostly has to do with the consequences of the error.

On the one end of the spectrum are trivial errors that have no real consequence (not displaying some background image). On the other hand, there's irrevocable data corruption.

Failing is a way of preventing that (subtle) data corruption can go unnoticed for a long time before it is detected. If something goes wrong with your financial or medical data (or whatever else is very important), you want alarm bells ringing, lights flashing, and preventing anything from doing more damage, right then and there. You want to make failure noted and the chances of things slipping through very minimal.

That of course comes at the cost of bothering people with ringing alarm bells, flashing lights and the unability to proceed: it stops things from working, it annoys people, it needs time and effort to correct. So for very trivial errors the cost of all those bells and wistles is too much and you want to make failure silent and try to make the best of things, at the risk of letting things slip through uncaught.

That's the balance. This applies for the viewpoint of the end user as much as the developer, btw. Allowing errors to go unnoticed makes it easier for things to slip by the developer, requiring less effort to make it just continue working, but more effort to catch all problems. Requiring explicit try-catches will not let errors go unnoticed, but requires more effort for the trivial cases.

(Btw, both mechanisms can still be used and abused: you can perfectly well log all the errors in php, and you can no doubt build some filthy empty catch-all construction in ASP.)

Answer 3

"Better" is a challenging world. IMO, the asp.net approach is better, because you should handle errors across the site, and handle processing and removal of parts of the site in a separate way.

It is quite possible to design an asp.net site so that errors do not cause problems in other parts of the site. I think the real issue is about building sites that are error-tolerant, which is a good idea. At the same time, if there are errors, they should always be reported.

The danger is that errors are ignored because they do not get in the way of normal useage.

Answer 4

I am guessing that the most suitable answer for your question is: Move to PHP. :) I personally prefer it because of the flexibility it has as also it is wide spread across the web.