Question:how to Handling Exceptions in ASP.NET MVC?

asked Sep 13, 2013 in Java Interview Questions by ashish singh
edited Sep 12, 2013
0 votes

1 Answer

0 votes


Try-Catch everywhere
You've seen this code before, right?
public void DoSomething()
        var x = 1;
    catch (Exception ex)
The approach of putting try-catch block around every ounce of code seems like a good idea intuitively.  Sure, you're showing the user an ugly error message, but it's better than crashing the server.
But what is the user supposed to do with the information you show them?  How are they supposed to fix your null reference exception?
The other knock on this approach is there is so much ceremony code!
Generic error page
This approach goes the other way with a generic error page displayed to the user for any unhandled error.  It's easy to implement in the Web.config file, and the user never sees a null reference exception or stack trace.
Here's what I'm using:
There are two problems with the generic error page approach.  First, the user has no information about what happened.  Maybe it's something they could have resolved?  Maybe they should try again later?  Just saying "Pardon our mess" doesn't give them any details.
Second, it doesn't give you any details either.  The next time you talk to the user, they will tell you they got an error in your app.  "Oh, what happened?" you'll ask. 
"Uh, it was on that screen with the customer info.  I forgot what I was doing, but it just showed the error screen, so I rebooted and went home for the day."  Not much to go on.  Something about the customer screen?  This will be a fun one to try to reproduce!
Just log it
The last approach is to log all errors.  You collect as much detail as you need.  The date and time the exception was thrown, which user/IP address, which server they were on, the stack trace, etc.
Error logging can be extensive and can be stored in rolling text files or database tables.  I prefer using the database so I don't need to grant write permissions to the ASP.NET process running that web app.
Here's an Application_Error event from a couple projects back:
protected void Application_Error(object sender, EventArgs e) 
    var ctx = HttpContext.Current;
    var ex = ctx.Server.GetLastError();
    if (ex != null)
I've done lots of applications like this, where the Application_Error event in Global.asax calls into a logger like log4net or Enterprise Library to store exception details.  It works great.  You get the details you need to fix the bug.
But what about the user?  What are the users looking at when this exception is thrown?
#3 Combo Platter
Today, I'm using bits and pieces of all of these. 
I show the user a generic error page for all unhandled exceptions.  It may not have much info, but something weird just happened in the app and I wasn't expecting it.  I need more information about what happened so I can decide what needs to be done.
That's why I'm also using ELMAH to log all unhandled exceptions.  The exception details get stored in my database and I even get a fancy exception viewer since ELMAH works as an Http Handler.  My favorite ELMAH feature is you can usually see the yellow screen you would have seen if running locally on your box.
Finally, sometimes there are handled exceptions.  This is where an exception occurred before in the code (database is down, file not found, etc.), it might occur again, and I've got some thoughts about what to do next time it happens.
In my view, the only place you need try-catch blocks is when you are worried that an exception might happen and you want to give the user some information, give the user instructions, or silently fix the problem yourself.  If I can't do one of these, I just show the "Oops" page try to come up with a plan later.
For instance, if the database is down, I'd tell the user to try again later, but I couldn't save their record right now.  If the user is trying to upload a file and it's not there, they can try to correct the file upload input box and resubmit.
answered Sep 13, 2013 by ashish singh
edited Sep 12, 2013