CODEWITHSUNDEEP
c#asp.net-mvcentity-framework
JoanieBrar
JoanieBrar

Reputation: 151

Strategy for handling unexpected database results on your website

Maybe more of a general question than a .NET question, but in an instance where we get a database result that goes against expectation based on our understanding of the database structure (at the time of writing code), what do we do?

Take the code below; based on the fact that the "DataRetrievalName" of Model "DataRetrievals" is assumed to be unique at the time of coding, I should never get an InvalidOperationException. In the scenario where I do, it seems a bit phoned in to just pass the error message to the View, no? Thoughts on handling/logging strategies for these scenarios? 

    public ViewResult Edit(string resultSetToFind)
    {

        DataEntities db = new DataEntities();
        DataResultSet viewModel = new DataResultSet();
        try
        {
            //single resultset not found
            viewModel.ResultSet = db.DataRetrievals.Single(r => r.DataRetrievalName == resultSetToFind);

        }
        catch (System.ArgumentNullException exception) {
            //resultset not found
            viewModel.ErrorMessage=System.Web.Http.WebHost.Properties.ErrorMessages.ResultSet_NameNotFound;                 
        }
        catch (System.InvalidOperationException exception) { 
            //more than one entry found, this should never happend
            viewModel.ErrorMessage = System.Web.Http.WebHost.Properties.ErrorMessages.ResultSet_DuplicateNameFound;
        }
        return View(viewModel);

    }

Upvotes: 1

Views: 63

Answers (1)

Rowan Freeman
Rowan Freeman

Reputation: 16358

This is a pretty broad question. How exactly you go about handling errors is really up to your application. I'll provide what hints I can.

pass the error message to the View

Don't pass the error to the user.

Unless your application specifically requires it (perhaps an intranet could be an exception), the user doesn't need to know anything about the error. They probably don't care and, if they do, they might want to know for malicious reasons.

There is no need to show, for example:

ERROR 9001: Connection timeout for user 'root'@'200.100.50.25' (using password: NO)

An exaggeration, perhaps, but something bad could be revealed.

Instead, show a generic and friendly error page and state that something unexpected happened. Explain that is not the fault of the user and that a team of highly trained monkeys has been dispatched to deal with the situation.

Don't handle errors in controllers.

Well, maybe not never, but handling errors in controllers should be avoided. Try-catch blocks are very verbose and can quickly make code ugly and cumbersome. Controller actions should be as small and brief as possible.

Instead, I would recommend utilising Error Attributes.

public class DatabaseErrorAttribute : HandleErrorAttribute
{
    public override void OnException(ExceptionContext filterContext)
    {
        // log exception and other details
    }
}

You can handle different types of errors separately or simply use a generic error handler to capture everything. Either way you should log the error with as much detail as possible so that someone can investigate and fix the problem.

You can apply error attributes to individual actions, whole controllers or even the entire application.

Upvotes: 1

Related Questions