Are there any docs on how to correctly implement ExceptionFilterAttribute? For instance:
What happens when you set context.Result? Will it serialize that result as the overall response? Does it stop applying any further filters?
What happens when you set context.ExceptionHandled? Does that mean "I'm done processing exceptions, please send the response to the client", or does that mean "I've recovered from the exception, continue processing the request"?
When do you call base.OnException or base.OnExceptionAsync, at the beginning or the end? Do you only call it when your implementation doesn't handle the given exception?
Etc.
There's no official doc on this and it's not the most obvious thing to implement, so does anyone have either a) good docs - maybe a blog post, or b) a correct sample implementation?
Documentation about filters in ASP.NET Core.
Documentation about error handling.
Exception filters handle unhandled exceptions that occur in controller creation, model binding, action filters, or action methods. They won't catch exceptions that occur in Resource filters, Result filters, or MVC Result execution.+
To handle an exception, set the ExceptionContext.ExceptionHandled property to true or write a response. This stops propagation of the exception. Note that an Exception filter can't turn an exception into a "success". Only an Action filter can do that.
Exception filters are good for trapping exceptions that occur within MVC actions, but they're not as flexible as error handling middleware. Prefer middleware for the general case, and use filters only where you need to do error handling differently based on which MVC action was chosen.
Regarding "Does it stop applying any further filters?":
Further pipeline execution is stopped if you have unhandled exception, as current method execution is stopped) and exception go up the stack until it is caught in a higher level catch block.
But keep in mind, that final implementation of ExceptionFilterAttribute logic is still in progress. Some changes are expected in next .NET Core MVC 1.1.2.
I have found the following useful explanation is github issue (Exception Filters returns an empty body):
Have confirmed IActionFilters in MVC 5.2.3 and ASP.NET Core 1.1.0 behave the same. However, IExceptionFilters behave differently w.r.t. setting Result but leaving ExceptionHandled==false. Should remove this special case around setting Result.
1.1.0 behaviour is also a regression compared to ASP.NET Core 1.0.x.
Long story about a consistent behaviour for ASP.NET Core:
Users can short-circuit most IFilterMetadata implementations by setting Result. But, only on the way in e.g. OnActionExecuting() can short-circuit but OnActionExecuted() cannot.
To short-circuit IExceptionFilter implementations (which are only called on the way out), users must set ExceptionHandled==true.
Setting ExceptionHandled==true in all IFilterMetadata implementations also ensures an Exception thrown in an action is not rethrown. An overridden Result is used in that case.
In a small, intentional deviation from MVC 5.2.3, setting Exception==null is handled identically to setting ExceptionHandled==true.
I have an exception that is being thrown in Grails. Looking at the stack trace is helpful because I can see where the code bombed, but it turns out it is only bombing for one record out of hundreds, so it would be helpful to know what the values of the variables in memory are at the time of the exception. For example, in Visual Studio, when an Exception occurs, everything is paused on the line that throws the exception and all variables in memory are available to look at.
Is there anything like this for Grails (or Spring Source Tool Suite/Eclipse)? Is there a way to dump all variables to standard out? Thanks.
It sounds like you want to set an exception breakpoint, one that is triggered only when a particular type of exception is thrown.
Also, if you are using STS you can set conditional breakpoints in groovy code (and of course you can set conditional breakpoints in Java in either STS or Eclipse, but only STS allows this for Groovy).
"Hundreds" is not a number that is unmanageable. Can you connect to your application with a remote debugger and attach a breakpoint? In Intelli-J, you can start a server in debug mode; unsure how you do it in eclipse STS/vanilla grails, aside from deploying a war into a tomcat container with remote debug connections enabled.
My question is: how would you create exception hierarchy in your application?
Designing the architecture of an application,
from my perspective, we could have three types of exceptions:
the built-in (e.g.: InvalidOperationException)
custom internal system faults (database transaction failed on commit, DbTransactionFailedException)
custom business exceptions (BusinessRuleViolationException)
Class hierarchy:
Exception
MyAppInternalException
DbTransactionFailedException
MyServerTimeoutException
...
MyAppBusinessRuleViolationException
UsernameAlreadyExistsException
...
where only MyAppInternalException & MyAppBusinessRuleViolationException would be catched.
The real benefit of exception type E inheriting from type F is apparently when E is caught by a module that doesn't specifically know what E is, but does know about F. Assuming the inheritance makes sense, the module has a reasonable hope of taking the right corrective action for an E exception, based on it being a kind of E exception.
So I tend to class exceptions according to how they can reasonably be handled. For example, a typical business process might use something like:
ConfigurationException -- things that can be fixed by changing a config file. E.g. config cannot be parsed or is not consistent. Appropriate response is to warn the user to fix the config (with helpful hints if possible).
InfrastructureException -- things that can sporadically go wrong with resources outside the program's control, like remote servers, etc. Appropriate response is often to disconnect and retry after a pause, and give up if there are too many failures.
DataException -- things that are wrong in incoming data. An appropriate response is to log the complaint (and possibly the data) and ignore this message.
These can be subclassed of course. But distinction at that level is often more useful to modules closer to the source of the exception. If an exception bubbles all the way to main module then there are usually only a few possible actions, and it easiest to have a one-to-one correspondence between those actions and the catch statements they respond to.
"UsernameAlreadyExistsException"
I think you shouldn't use an exception to control regular flow of your application. i.e. This is a regular business case and shouldn't appear as an exception. There is no MyAppBusinessRuleViolationException in a correct application design.
Regards,
What are the best practices for exceptions over remote methods?
I'm sure that you need to handle all exceptions at the level of a remote method implementation, because you need to log it on the server side. But what should you do afterwards?
Should you wrap the exception in a RemoteException (java) and throw it to the client? This would mean that the client would have to import all exceptions that could be thrown. Would it be better to throw a new custom exception with fewer details? Because the client won't need to know all the details of what went wrong. What should you log on the client? I've even heard of using return codes(for efficiency maybe?) to tell the caller about what happened.
The important thing to keep in mind, is that the client must be informed of what went wrong. A generic answer of "Something failed" or no notification at all is unacceptable. And what about runtime (unchecked) exceptions?
It seems like you want to be able to differentiate if the failure was due to a system failure (e.g. a service or machine is down) or a business logic failure (e.g. the user does not exist).
I'd recommend wrapping all system exceptions from the RMI call with your own custom exception. You can still maintain the information in the exception by passing it to your custom exception as the cause (this is possible in Java, not sure about other languages). That way client only need to know how to handle the one exception in the cause of system failure. Whether this custom exception is checked or runtime is up for debate (probably depends on your project standards). I would definitely log this type of failure.
Business type failures can be represented as either a separate exception or some type of default (or null) response object. I would attempt to recover (i.e. take some alternative action) from this type of failure and log only if the recovery fails.
In past projects we'd catch all service layer (tier) exceptions at the very top of the layer, passing the application specific error codes/information to the UI via DTO's/VO's. It's a simple approach in that there's an established pattern of all error handling happening in the same place for each service instead of scattered about the service and UI layers.
Then all the UI has to do is inspect the DTO/VO for a flag (hasError?) and display the error message(s), it doesn't have to know nor care what the actual exception was.
I would always log the exception within my application (at the server side as defined in your question).
I would then throw an exception, to be caught by the client. If the caller could take corrective action to prevent the exception then I would ensure that the exception contained this information (e.g. DateTime argName must not be in the past). If the error was caused by some outage of a third party system then I might pass this information up the call stack to the caller.
If, however, the exception was essentially caused by a bug in my system then I would structure my exception handling such that a non-informative exception message (e.g. General failure) was used.
Here's what I did. Every Remote Method implementation catches all Exceptions on the server side and logs them. Then they are wrapped in a Custom Exception, which will contain a description of the problem. This description must be useful to the client, so it won't contain all the details of the caught Exception, because the client doesn't need them. They have already been logged on the server side. Now, on the client, these Exceptions can be handled how the user wishes.
Why I chose using Exceptions and not return codes is because of one very important drawback of return codes: you can't throw them to higher levels without some effort. This means you have to check for an error right after the call and handle it there. But this may not be what I want.
I've seen the following code many times:
try
{
... // some code
}
catch (Exception ex)
{
... // Do something
throw new CustomException(ex);
// or
// throw;
// or
// throw ex;
}
Can you please explain the purpose of re-throwing an exception? Is it following a pattern/best practice in exception handling? (I've read somewhere that it's called "Caller Inform" pattern?)
Rethrowing the same exception is useful if you want to, say, log the exception, but not handle it.
Throwing a new exception that wraps the caught exception is good for abstraction. e.g., your library uses a third-party library that throws an exception that the clients of your library shouldn't know about. In that case, you wrap it into an exception type more native to your library, and throw that instead.
Actually there is a difference between
throw new CustomException(ex);
and
throw;
The second will preserve the stack information.
But sometimes you want to make the Exception more "friendly" to your application domain, instead of letting the DatabaseException reach your GUI, you'll raise your custom exception which contains the original exception.
For instance:
try
{
}
catch (SqlException ex)
{
switch (ex.Number) {
case 17:
case 4060:
case 18456:
throw new InvalidDatabaseConnectionException("The database does not exists or cannot be reached using the supplied connection settings.", ex);
case 547:
throw new CouldNotDeleteException("There is a another object still using this object, therefore it cannot be deleted.", ex);
default:
throw new UnexpectedDatabaseErrorException("There was an unexpected error from the database.", ex);
}
}
Sometimes you want to hide the implementation details of a method or improve
the level of abstraction of a problem so that it’s more meaningful to the caller
of a method. To do this, you can intercept the original exception and substitute
a custom exception that’s better suited for explaining the problem.
Take for example a method that loads the requested user’s details from a text file. The method assumes that a text file exists named with the user’s ID and a suffix of “.data”. When that file doesn’t actually exist, it doesn’t make much sense to throw a FileNotFoundException because the fact that each user’s details are stored in a text file is an implementation detail internal to the method. So this method could instead wrap the original exception in a custom exception with an explanatory message.
Unlike the code you're shown, best practice is that the original exception should be kept by loading it as the InnerException property of your new exception. This means that a developer can still analyze the underlying problem if necessary.
When you're creating a custom exception, here's a useful checklist:
• Find a good name that conveys why the exception was thrown and make sure that the name ends with the word “Exception”.
• Ensure that you implement the three standard exception constructors.
• Ensure that you mark your exception with the Serializable attribute.
• Ensure that you implement the deserialization constructor.
• Add any custom exception properties that might help developers to understand and handle your exception better.
• If you add any custom properties, make sure that you implement and override GetObjectData to serialize your custom properties.
• If you add any custom properties, override the Message property so that you can add your properties to the standard exception message.
• Remember to attach the original exception using the InnerException property of your custom exception.
You typically catch and re-throw for one of two reasons, depending on where the code sits architecturally within an application.
At the core of an application you typically catch and re-throw to translate an exception into something more meaningful. For example if you're writing a data access layer and using custom error codes with SQL Server, you might translate SqlException into things like ObjectNotFoundException. This is useful because (a) it makes it easier for callers to handle specific types of exception, and (b) because it prevents implementation details of that layer such as the fact you're using SQL Server for persistence leaking into other layers, which allows you to change things in the future more easily.
At boundaries of applications it's common to catch and re-throw without translating an exception so that you can log details of it, aiding in debugging and diagnosing live issues. Ideally you want to publish error somewhere that the operations team can easily monitor (e.g. the event log) as well as somewhere that gives context around where the exception happened in the control flow for developers (typically tracing).
I can think of the following reasons:
Keeping the set of thrown exception types fixed, as part of the API, so that the callers only have to worry about the fixed set of exceptions. In Java, you are practically forced to do that, because of the checked exceptions mechanism.
Adding some context information to the exception. For example, instead of letting the bare "record not found" pass through from the DB, you might want to catch it and add "... while processing order no XXX, looking for product YYY".
Doing some cleanup - closing files, rolling back transactions, freeing some handles.
Generally the "Do Something" either involves better explaining the exception (For instance, wrapping it in another exception), or tracing information through a certain source.
Another possibility is if the exception type is not enough information to know if an exception needs to be caught, in which case catching it an examining it will provide more information.
This is not to say that method is used for purely good reasons, many times it is used when a developer thinks tracing information may be needed at some future point, in which case you get try {} catch {throw;} style, which is not helpful at all.
I think it depends on what you are trying to do with the exception.
One good reason would be to log the error first in the catch, and then throw it up to the UI to generate a friendly error message with the option to see a more "advanced/detailed" view of the error, which contains the original error.
Another approach is a "retry" approach, e.g., an error count is kept, and after a certain amount of retries that's the only time the error is sent up the stack (this is sometimes done for database access for database calls that timeout, or in accessing web services over slow networks).
There will be a bunch of other reasons to do it though.
FYI, this is a related question about each type of re-throw:
Performance Considerations for throwing Exceptions
My question focuses on "Why" we re-throw exceptions and its usage in application exception handling strategy.
Until I started using the EntLib ExceptionBlock, I was using them to log errors before throwing them. Kind of nasty when you think I could have handled them at that point, but at the time it was better to have them fail nastily in UAT (after logging them) rather than cover a flow-on bug.
The application will most probably be catching those re-thrown exceptions higher up the call stack and so re-throwing them allows that higher up handler to intercept and process them as appropriate. It is quite common for application to have a top-level exception handler that logs or reports the expections.
Another alternative is that the coder was lazy and instead of catching just the set of exceptions they want to handle they have caught everything and then re-thrown only the ones they cannot actually handle.
As Rafal mentioned, sometimes this is done to convert a checked exception to an unchecked exception, or to a checked exception that's more suitable for an API. There is an example here:
http://radio-weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
If you look at exceptions as on an alternative way to get a method result, then re-throwing an exception is like wrapping your result into some other object.
And this is a common operation in a non-exceptional world. Usually this happens on a border of two application layers - when a function from layer B calls a function from layer C, it transforms C's result into B's internal form.
A -- calls --> B -- calls --> C
If it doesn't, then at the layer A which calls the layer B there will be a full set of JDK exceptions to handle. :-)
As also the accepted answer points out, layer A might not even be aware of C's exception.
Example
Layer A, servlet: retrieves an image and it's meta information
Layer B, JPEG library: collects available DCIM tags to parse a JPEG file
Layer C, a simple DB: a class reading string records from a random access file. Some bytes are broken, so it throws an exception saying "can't read UTF-8 string for record 'bibliographicCitation'".
So A won't understand the meaning of 'bibliographicCitation'. So B should translate this exception for A into TagsReadingException which wraps the original.
THE MAIN REASON of re-throwing exceptions is to leave Call Stack untouched, so you can get more complete picture of what happens and calls sequence.