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.
There is a good project called Elmah for logging errors and exceptions in ASP.NET applications. You can find it here