User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

closed as not a real question by Jimmy Breck-McKye, Assaf Lavie, Emil, Charles Boyung, Ben Brocka Nov 11 '11 at 20:26

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Which user? The developer? The end-user? What's the user's concern? Why are they using the service? Is this a context where partial functionality is worse than no functionality, or where something dangerous might happen? We need more information. – Jimmy Breck-McKye Oct 30 '11 at 12:50
No, @JimmyBreck-McKye, I'm asking this question in general. You know, for example more clicks are always bad. You'd better reduce clicks from 20 to 10 for a wizard. This is general question and has no specific context. – Saeed Neamati Oct 30 '11 at 12:57
Then my answer has to be similarly general: "It depends - and on too many factors list in a reasonable word count". If you want something more specific, then you need to revise your question. – Jimmy Breck-McKye Oct 30 '11 at 13:03
More to the point, you need to understand that there aren't any 'general' usability questions. I'm sorry, but contrary to popular myth, there are no magic rules like 'right align your field labels and everything will be fine'. Even that 'less clicks is better' maxim is pretty dubious. Without context, a UX decision is meaningless. – Jimmy Breck-McKye Oct 30 '11 at 13:10
Well, I disagree. But let's see if someone has an answer with reasons or not. Thanks for your notes. :) – Saeed Neamati Oct 30 '11 at 13:13

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.

enter image description here

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.

share|improve this answer
Good examples and nice analysis @BenBrocka. +1. – Saeed Neamati Oct 31 '11 at 4:09

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.)

share|improve this answer

"Better" is a challenging world. IMO, the 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 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.

share|improve this answer
While error handling is extremely important for UX, error reporting isn't. Error reporting should be entirely silent unless user feedback is needed (but these are probably "bugs" not actual errors to the programming language). – Ben Brocka Oct 30 '11 at 16:48
By "Reporting" I mean recording them somewhere, not displaying. I think the question goes over UX and SO issues. – Schroedingers Cat Oct 30 '11 at 16:58

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.