Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

Are there any cases when error 500 is acceptable to be returned? Or should we always try to handle all server-side exceptions and return another code with a user-friendly informative error message?

share|improve this question

4 Answers 4

up vote 2 down vote accepted

No. If you ask a normal person (i.e. a non geek) they will most likely think that they have done something wrong. You should always try and be as user friendly as possible. Also the stack trace should never be visible in a production system as that is exactly what hackers are looking for.

One thing we used to do was in a test environment was to surface the stack trace in the HTML source as comments so the test automation can easily access it.

Also I have seen white text on white background to display the text in production, so you only needed to highlight the white section to see it, but this is a bad idea as most hackers will use their own client side source, not yours.

share|improve this answer

Our applications display a user-friendly message to the user with an error code in brackets beside it to avoid the "Error hiding" design anti-pattern. In the particular case of a server timeout I use (500) beside the friendly text message that "There was a problem completing your request please try again later.", etc.. This is a friendly message to the user but also allows a technician to know what type of failure occurred if the user contacts us about it.

share|improve this answer

The wording of the question and the answers seem to miss a subtlety in what you're asking. To not break HTTP, you should always return as a 500. You never redirect to an error page (and give a 200 OK if something bad happened).

Now, whether or not you're bubbling up the stack trace, or just giving a simple "something bad happened" - that's another story. Web and app server trickery can be used to mask the specifics while still returning the proper HTTP status code. So the simple answer is yes return 500, but yes swallow the exception details before delivering the page to the end user.

share|improve this answer
    
Indeed it's important that your HTTP response code != what you display to user. (Anecdote: Once my friend was pissed off because a client was idling with payment, and what he did is he made response codes of all site pages to be 402 ‘Payment Required’ instead of 200. Since page content wasn't changed, the site looked normal, so it was kind of ineffective… but fun =)) –  Anton Strogonoff Apr 13 '12 at 17:54

In production, our web application shows a friendly message. While manual testing, we set a test flag that allows a stack trace to appear in the browser. When we are penetration testing or stress testing, we surface the HTTP 500.

share|improve this answer
    
It is generally more user friendly to return a friendly error message - however it isn't really harmful to return a vanilla 500 error and allow the browser to display their default error page for that exception. It goes without saying that you should never return the detailed 500 errors with stack trace info as that could compromise your site's security. A hacker who has access to detailed exception info and stack traces can use that to their advantage. –  Sam Woods Apr 9 '12 at 15:33
    
Agreed. When we manually test, we use a QA system with different credentials, not the production system. –  user246 Apr 9 '12 at 15:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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