Hi Karl,
the doc says the current order of handling is this:
1. Unwrap exception stack
2. Begin processing root cause
3. Invoke any callback methods annotated with @BeforeHandles for the
closest type to the exception
4. Find handler for the closest type to the exception
5. If multiple handlers for same type, invoke handlers with higher
ordinal first
6. Continue above steps for each exception in stack
The trouble is in step 4 - it begins with the root cause -
ConnectException - and doesn't find a handler for it, so in step 4, it
looks for the closest handler by class hierarchy - which is the generic
Exception handler. Only after that it goes a step higher in stack (step
6) to the SolrServerException.
This order seems a little counter-intuitive to me too.
On 1.3.2015 14:11, Karl Kildén wrote:
Hello,
I have a typical use case I can't figure out what I might misunderstand. I
have a java.net.ConnectException as root exception. This is wrapped by
SolrServerException. I want my handler on SolrServerException because the
ConnectionException is to broad and I can't draw any conclusions. However
the SolrServerException is easy to parse and print a good message to the
end user.
Problem is I have a general dump Handler that takes Exception and redirects
to error page. This is where my exception ends up BEFORE handler that
takes SolrServerException. I want it to try to whole chain up to the outer
cause before going to my handler that takes Exception...
Cheers
--
Ron Smeral
JBoss Quality Engineer
Brno
