This gist has been updated (see history for previous discussions) and aims to discuss solutions to AEROGEAR-426 "General/fall-back error page on Controller".
aerogear-controller branch
aerogear-controller-demo branch
Example of specifying a single exception:
@Override
public void configuration() throws Exception {
route()
.on(DeloreanException.class)
.to(ExceptionHandler.class).errorPage();
route()
.from("/")
.on(RequestMethod.GET)
.to(Home.class).index();
}
Example of specifying multiple exceptions:
@Override
public void configuration() throws Exception {
route()
.on(DeloreanException.class, SomeOtherException.class)
.to(ExceptionHandler.class).errorPage();
route()
.from("/")
.on(RequestMethod.GET)
.to(Home.class).index();
}
It's possible for the errorPage to take an Exception as a parameter, for example if some action like logging should take place:
@Override
public void configuration() throws Exception {
route()
.on(DeloreanException.class, SomeOtherException.class)
.to(ExceptionHandler.class).errorPage(param(Exception.class));
route()
.from("/")
.on(RequestMethod.GET)
.to(Home.class).index();
}
In the above examples the errorPage would be resolved to WEB-INF/ExceptionHandler/errorPage.jsp.
To support multiple exceptions the on method of RouteBuilder looks like this:
TargetEndpoint on(Class<? extends Throwable> exception, Class<?>... exceptions);
Now, this is somewhat ugly and the second parameter is not typesafe (though runtime check is performed) but was the cleanest solution I could think of with regard to ease of use, and without polluting the API.
The issue here was to avoid compiler warnings about using varargs in combination with generics (Class) from client code (with @Safevarargs in Java7 which should be able to make this typesafe at compile time). Hopefully, with the first parameter being typed this will make it understandable for users and obvious that the classes following the first parameter should also be of the same type.
What are your thoughts on this?
@qmx Ah my mistake, I missed that the from() method was missing in the route in the Jira description :(
So, have I understood this correctly by saying that the below on(Exception) would handle any MyException thrown from any route declared within the same configuration() method?
Should this support a single Exception of should it be possible to specify multiple?
I see, I'll fix this and the other issues.
Out of curiosity, the use case I was thinking about with regard to sending a response, was a form being sent with invalid data, and that it might be useful to send a response rather than forwarding. Would such a use case be handled in some other way?
@abstractj on it is :)
Thx