What's the best way to handle exceptions that happen from within a controller's constructor?
All I can think of to do is use Application_OnError() or put a try/catch in my ControllerFactory.
Neither of these solutions seem ideal. Application_OnError is to broad - I have some non-mvc content in the site that has its own error handling.
Using a try/catch block seems kinda hacky.
If I'm serving different content type -html/text/json/rss.... I would like to be able to handle the exception from within the action method instead of having to write all kinds of conditions to determine what kind of error message to serve.
Am I missing something here, or has anyone else dealt with this?
If an exception is happening in your ControllerFactory when creating the controller in the first place, there's no way you can ever handle the exception in an action method.
Personally I would just do a try/catch, instantiate some error handling controller, and route the request through it instead.
A better question is - what are your controllers so dependent on that isn't being met that they have to throw exceptions when they're being constructed? Ostensibly, simply creating the controllers shouldn't be a huge source of exceptions. If they are, maybe you could look at lazily instantiating the dependencies in the action methods (rather than the constructor), and implementing an ErrorHandlingController approach. This would push the exceptions "down" into the controllers themselves, so you could take a more controller-centered approach to handling them.
Related
I am writing ASP.Net Web-form in VB.
I have a system which have already handled exceptions by try-catch blocks everywhere.
How do I quickly and generically implement exception logging like overriding something instead of inserting logging functions in every single catch block?
Using an AOP framework like Postsharp you can hook on exceptions thrown and log a message, but that will only work if you haven't already handled them in your code.
Your best bet would be to refactor your exception handling code. Apart from the global catch-all exception handling, you should only have try-catch blocks in places where you can actually handle the exception. And in those cases you probably want to add a specific message in the log telling why and how this exception was handled.
Curious what the best practice is for returning errors to a view from a controller where the error isn't really a validation error, but more like "user not found" or "service timeout" type of errors. (in ASP.NET MVC2 framework)
I've been adding them to the ModelState's model errors, but that doesn't seem appropriate. (although easy to implement and maintain)
Example - A user tries to log in, and their credentials do not match a known user.
I believe you need to be slightly more clear with regards to what youre calling an error.
Exceptions (timed out, database error, etc.) should be handled using specific exception handlers (not least because you often don't want to show the error message to the end user).
In this scenario, look at overloading the OnException() method on the controller. (or having all your controllers inherit from a common ControllerBase which has that method overriden to avoid repetition)
You may also want to check the value of filterContext.HttpContext.IsCustomErrorEnabled when handling exceptions to determine whether to expose detailed exception information or to obfuscate it.
Remember that exceptions should be for exceptional circumstances - "normal" operation should never result in an exception
The other type of error you're mentioning is more like "Unable to process request due to business rules / invalid input" (or similar) in which case, adding error messages to the ViewModel seems appropriate. They may not be direct validation errors but they are most likely as a result of the user input
I've just researched this, and I think that for network-related errors and so on, which are bound to happen, it's OK to use TempData (but don't put the Exception inside but the exception message only, for security reasons).
http://forums.asp.net/p/1460169/3353779.aspx
I am using ASP.net's AJAX framework and I am trying to do some exception logging on the javascript-called webservice.
Looking through the web, I find some people handling them client-side and sending them back to the server. I'd prefer not doing that since it relies on an other server call (if it failed the first time, sending an other request doesn't look like a good idea and that makes me change all my calls)
I see some other people decorating all their methods with try... catch blocks (which leads to duplicate error handling, and yet an other try catch block).
However, I'm trying to achieve something similar to global.asax's Application_Error() which handles every uncaught exception (nope, it doesn't seem to be called for AJAX called methods exceptions).
Is that even possible?
Use ELMAH - it can capture ajax errors.
I'm using JQuery to load controls dynamically in an ASP.NET development environment using JSON and WebServices. Within this solution I have a business logic layer which has a built in validation mechanism (i.e. validating properties and business rules similar to that of CSLA)
When requesting a new control to be loaded dynamically using JQuery and an ASP.NET WebService, I would like to validate the input from the current control against the business logic validation mechanism (i.e. server side validation) and notify the user if there was any problems.
I managed to achieve this, however, when validation fails in the web service I would like to throw a customer exception containing the validation field id's and associated error messages.
In JQuery, I test for this specific ExceptionType and would like to apply the error messages dynamically to the controls listed in the exception type properties. This is where my problem comes in. Even though I created a custom exception with custom properties the exception that is passed to JQuery in JSON format from the WebService is still a standard exception with none of the additional properties listed. I could simply create a JSON formatted string of values in the exception's message property but would ultimately prefer something a little more elegant. Does anyone know how you can override the serialized exception created by ASP.NET for situations such as this...
Thank you in advance...
G
I ran into something very similar a couple days ago - basically there's no way to make ASP.NET generate custom exceptions. This is by design, since returning a specific type of exceptions would
[...] expose implementation
details/bugs to the clients. We could
do something with special exception
type that we let pass through, but its
too late for this release [...]
You could always return different HTTP status codes, and have the browser handle them as custom exceptions - for example, a 500 error would mean one thing, a 401 something else, etc. I think the best solution is to make your method return a string with the exception stack - not elegant, but at least this way the client has all the exception details.
Dave Ward also has info on ASP.NET AJAX service errors.
I admit it: I don't bother with too much exception handling. I know I should do more but I can never wrap my head around where to start and where to stop. I'm not being lazy. Far from it. It's that I'm overwrought with exception handling ambivalence. It just seems that there is a seemingly infinite number of places in even the smallest app where exception handling can be applied and it can begin to feel like overkill.
I've gotten by with careful testing, validating, and silent prayer but this is a bad programming accident waiting to happen.
So, what are your exception handling best practices? In particular, where are the most obvious/critical places where exception handling should be applied and where are places where it should be considered?
Sorry for the vague the question but I really want to close the book on this once and for all.
Microsoft's Patterns & Practices team did a good job incorporating best practices of exception management into Enterprise Library Exception Handling Application Block
Event if wouldn't use Enterprise Library, I highly recommend you to read their documentation. P&P team describes common scenarios and best practices for exceptions handling.
To get you started I recommend read following articles:
Exception Handling on MSDN
Exception Management in .NET on MSDN
Exception Handling Best Practices in .NET on CodeProject
ASP.NET specific articles:
User Friendly ASP.NET Exception Handling
Global Exception Handling with
ASP.NET
Exception handling in C# and ASP
.Net
The golden rule with exception handling is:
"Only catch what you know how to handle"
I've seen too many try-catch blocks where the catch does nothing but rethrow the exception. This adds no value. Just because you call a method that has the potential to throw an exception doesn't mean you have to deal with the possible exception in the calling code. It is often perfectly acceptable to let exceptions propagate up the call stack to some other code that does know what to do.
In some cases, it is valid to let exceptions propagate all the way up to the user interface layer then catch and display the message to the user. It might be that no code is best-placed to know how to handle the situation and the user must decide the course of action.
I recommend you start by adding a good error page that catches all exceptions and prints a slightly less unfriendly message to the user. Be sure to log all details available of the exception and revise that. Let the user know that you have done this, and give him a link back to a page that will (probably) work.
Now, use that log to detect where special exception handling should be put in place. Remember that there is no use in catching an exception unless you plan to do something with it. If you have the above page in place, there is no use in catching database exceptions individually on all db operations, unless you have some specific way to recover at that specific point.
Remember: The only thing worse than not catching exceptions, is catching them and not doing nothing. This will only hide the real problems.
Might be more about exception handling in general than ASP.NET speific but:
Try to catch exceptions as close to
the cause as possible so that you
can record (log) as much information
about the exception as possible.
Include some form of catch all, last
resort exception handler at the
entry points to your program. In
ASP.NET this could be the
Application level error handler.
If you don't know how to "correctly" handle an exception let it bubble up to the catch all handler where you can treat it as an "unexpected" exception.
Use the Try***** methods in .NET
for things like accessing a
Dictionary. This helps avoid major
performance problems (exception
handling is relatively slow) if you
throw multiple exceptions in say a
loop.
Don't use exception handling to
control normal logic of your
program, e.g. exiting from a loop via
a throw statement.
Start off with a global exception handler such as http://code.google.com/p/elmah/.
Then the question comes down to what kind of application are you writting and what kind of user experience do you need to provide. The more rich the user experience the better exception handling you'll want to provide.
As an example consider a photo hosting site which has disk quotas, filesize limits, image dimension limits, etc. For each error you could simply return "An error has occured. Please try again". Or you could get into detailed error handling:
"Your file is to large. Maximum
filesizes is 5mb."
"Your image is is
to large. Maximum dimensions are
1200x1200."
"Your album is full.
Maximum storage capacity is 1gb".
"There was an error with your
upload. Our hampsters are unhappy.
Please come back later."
etc. etc.
There is no one size fits all for exception handling.
Well at the very basic level you should be handling the HttpApplication.Error event in the Global.asax file. This should log any exception that occurs to a single place so you can review the stack trace of the exception.
Apart from this basic level you should ideally be handling exceptions where you know you can recover from them - for example if you expect a file might be locked then handling the IOException and reporting the error back to the user would be a good idea.