Does it suck to not provide graceful errors to a user who doesn't use the website properly?

Question

I recently received a feedback from a colleague about my source code of a website. He says that it is a bad practice to not handle gracefully what visual interface does not allow to do.

Since it's not very clear, here's an example.

Let's say a visitor can comment something.

• A comment is saved into a database, in a nvarchar(500) column.
• The <input /> field length is limited to 500.

But, of course, nothing forbids to a more advanced user to disable the length limit and to type 501 character.

(Other examples: submitting an option which does not even exist in a <select />. But there is a graceful error when the user is asked to enter a number, and she enters a non-number instead, since keypress events are controlled through JavaScript, and JavaScript may be disabled)

If the visitor does so, there would be a failure on code contracts level. The AJAX request would fail with an unexpected error (or, on page submit, there will be an unexpected error). In all cases, the visitor will see that something wrong happened, but will have no graceful message indicating that the length of the submitted comment is too long.

Why is it bad practice? Why would I bother to design clear and explicit error messages for the cases where the visitor who uses correctly the website will never have?

---

Note: I understand that it sucks to display a .NET Framework detailed error and a stack trace when something like this happens. If I do so, it's a serious security issue. But in my case, there is just an AJAX response with something very generic or a redirect to a generic page with the apologizes about an error.

Answer 1

Since everyone appears to be missing your actual question, I'll put in my 2c (though I'll no doubt be downvoted in retaliation)

As long as your inputs are validated server side (your client-side maxlength is probably ok, though some obscure browsers may not support it), you can return a generic error message as long as it contains no exception information (which you have stated it doesn't).

If, however, it's possible to fail validation via lack of javascript or incorrect entry, then a custom error message should be provided for the sake of the user's sanity.

In short, what you are doing is fine.

Answer 2

First an most importantly

You should validate everything the user supplies on the server! This means not letting 501 letters through

Other than that if an unhandled exception occurs you should show the user a message which gives nothing away. If you were to return exception information this is gold dust to an attacker.

The best method is to display a general error such as "We're sorry, we're working on the problem straight away" and e-mail the exception information to the developers in order for them to fix it.

Answer 3

Why would I bother to design clear and explicit error messages for the cases where the visitor who uses correctly the website will never have?

If everyone used the web correctly, we'd never need to have validation.

As Ronald Reagan once said, "Trust, but verify".

Put in server-side validation for the length of fields. Put in validation to make sure there aren't any XSS or SQL Injection attacks. It's not the people who use your site correctly that you have to worry about, it's the ones that use it maliciously.