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?

5 Answers 5


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.

  • Any of the 5xx error code will result in the page content to be displayed normaly. So while the page content should display user friendly content, it is good practice to use the proper http status code. If you return a faked 200 status code, search engine such as Google will update their index with the error message, overwriting the real content. /// Proper advise is to return the correct http error status code with a user friendly message. Sep 8, 2016 at 9:36

From the question I'm understanding that you are asking if it is okay to allow the default white page with critical information of probably the page and line number of the code where the error occurred to display in the front-end/production environment/user side.

Simplest and most appropriate answer (as per my understanding) is NO.

The reason being this discloses critical data which malicious users (hackers) like to exploit. Instead of this have a custom error page for error status codes like 500, 503, 404, 403 and any other error status and wherever such an error occurs redirect users to the respective custom error page which will display a custom and more user friendly error message.


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.

  • 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 =)) Apr 13, 2012 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.

  • 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, 2012 at 15:33
  • Agreed. When we manually test, we use a QA system with different credentials, not the production system.
    – user246
    Apr 9, 2012 at 15:50

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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