Karl, a few options: 1) Modify the exception stack to take out the ConnectionError: https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/exception/control/ExceptionHandlerBroadcaster.java#L81 You'd listen for that event and modify the stack itself. That one may not be documented, I don't recall.
2) Return SKIP_CAUSE from your handler if it's the ConnectionException 3) As I stated in the previous email, use a @BeforeHandler to handle the ConnectionException The standard use case that the exception handling was originally designed to cover from Seam 3 Catch was in an EE environment, where your exceptions are often times wrapped in useless wrappers like EJBException or a generic PersistenceException for example. Also, more often than not you need the root cause of the exception instead of the wrapper. People of course are free to use the exception handling however they'd like, but it was originally envisioned to have lots of smaller controllers for each exception type and maybe a generic Exception handler for things like logging. On Mon, Mar 2, 2015 at 9:53 AM, Karl Kildén <[email protected]> wrote: > Hello, > > thanks guys. I don't find my general purpose guy useless because for > optimistic locking exception I say for example "someone else edited, do > this" and for connection exception I want to say something else. For a > nullpointer however I want to redirect to errorpage and show error codes > and stuff... > > But now even for optimistic locking it shows error page instead. So I have > logic in my general purpose handler, really I would like it to be > "afterHandles" and check if nobody did anything it can take care of it... > Logic is fine but pretty ugly. > > > > On 2 March 2015 at 16:34, Ron Smeral <[email protected]> wrote: > > > 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 > > > > > -- Jason Porter http://en.gravatar.com/lightguardjp
