Menu
I've recently joined an asp.net mvc project well under way where there isnt much consistency in dealing with exceptions in the controller; some devs return data to the client to let the user know whats wrong, others throw them back so they get to the server-level handler that processes and logs them - without letting the user know whats up.
It seems obvious to me that both approaches are wrong on their own, and need to complement each other instead; what I'm stuck at, is how to do that. I assume the eventual exception handler / logger could redirect the user to an error webpage upon catching something particularly nasty, but that limits the mechanism to just severe stuff.
I'm kind of looking for a way to do both "throw" and "return ..." at a time when I catch an exception, so I get it sorted and logged server side and get data client side that lets me tell the user there's been a hiccup.
My expertise with asp.net is very limited, and while I believe I understand mvc enough for it to not be an issue, this is kind of a "what is the best practice?" question from someone working with people who dont bother with best practices much.
969
Throwing an exception is as simple as using the "throw" statement. You then specify the Exception object you wish to throw. Every Exception includes a message which is a human-readable error description. It can often be related to problems with user input, server, backend, etc.
When an exception is thrown using the throw keyword, the flow of execution of the program is stopped and the control is transferred to the nearest enclosing try-catch block that matches the type of exception thrown. If no such match is found, the default exception handler terminates the program.
There is a good project called Elmah for logging errors and exceptions in ASP.NET applications. You can find it here
ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.
Once ELMAH has been dropped into a running web application and configured appropriately, you get the following facilities without changing a single line of your code:
- Logging of nearly all unhandled exceptions.
- A web page to remotely view the entire log of recoded exceptions.
- A web page to remotely view the full details of any one logged exception, including colored stack traces.
- In many cases, you can review the original yellow screen of death that ASP.NET generated for a given exception, even with customErrors mode turned off.
- An e-mail notification of each error at the time it occurs.
- An RSS feed of the last 15 errors from the log.
102
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
