Question

I have a web-application: ExtJs frontend – EntityFramework + SQL Server as a backend. Let’s take a look at one of the error scenarios:

• I have database constrains for username (name must be unique)
• I don’t have any client side validation for that (should I? is there way to make such validation generic?)
• Server returns 500 error if I try to insert user with the same name.
• If I run it from the same machine IIS is on – I get full error message (basically SQL exception description with key violation etc), if I run it from other machine – I just get 500 error and no error message.

What’s the best approach to handle this? I need to tell user in some human readable format about the error. I really don’t want to turn on error messaging on the IIS because it’s not a good practice.

Answer 1

I think you don’t have an error here, but a business rule violation.

I like to differentiate both of them, being the first some unexpected situation (like a database conection loss) and the later some scenario that you know its likely to happen.

For errors, I think the appropiate is to inform the user in a generic fashion (say, “an unexpected error has ocurred”) because its something that the user can’t correct nor need detailed information.

On the other hand, a business rule is something that the user might understand and can take action to correct (here, the user name constraint). So it should be notified to the user.

In projects I’ve worked on, we have a type of exception, BusinessException. We throw it with a message indicating what was the problem and it renders in a human readable format. We don’t explicity try-catch this exceptions, but use a handler to manage them. If you’re using MVC, there is an extension hook where you can do it.

For other types of exceptions, its a good practice to log the stacktrace somewhere (i.e. EventViewer), but not give the user the details.

In this case, I would do the following:

• Have a button check names to allow the user pre-validate the name.
• The place to validate the name, depends on where you want to have your application’s business logic. On the DB, using stored procedures, is an approach, but if you’re using EF, this means that you want to abstract from the data access. Instead, you can write this validation by yourself, using LINQ (something like Context.Users.SingleOrDefault(x => x.Name == name) and then check whether it returns null or some user. You might think this validation is not neccesary as you already have your DB constraint, but doing this way, the logic remains in your application’s code.
• Capturing an exception from EF could be messy, because you need to check a SQL error code to determine whether it was a constraint violation or other error. And even if you determine that, you need to transform the message into a user friendly one.

I hope this helps you in your decision!