[seam-issues] [JBoss JIRA] Issue Comment Edited: (SEAMCATCH-31) change terminology for exception type hierarchy traversal

[Dan Allen (JIRA)]

    [ https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571123#comment-12571123 ] 

Dan Allen edited comment on SEAMCATCH-31 at 12/17/10 2:07 PM:
--------------------------------------------------------------

I realize my proposal will change how things are done (when considering both SEAMCATCH-31 and SEAMCATCH-32).

What I would like is for each exception in the chain to be handled in turn. We see if any handlers are interested in the inner exception (the cause). If we get to the end of processing that exception and no handler marked it as handled, then we need to move to the wrapper, and so on.

When handling a single exception in the stack, we then notify the handlers in a particular order. That order works breadth-first for handlers marked as such, then depth-first, which is the default phase (or mode) in which handlers get registered.

One way to think of the handler notification order is to think of them as JSF phase listeners, where the "before" is a super-type handler marked TraversalMode.BREADTH_FIRST and the "after" is a super-type handler marked TraversalMode.BREADTH_FIRST. Obviously, the actual event is the invocation of the handler for the specific type (which may not exist, btw).  

      was (Author: dan.j.allen):
    I realize my proposal will change how things are done (when considering both SEAMCATCH-31 and SEAMCATCH-32).

What I would like is for each exception in the chain to be handled in turn. We see if any handlers are interested in the inner exception (the cause). If we get to the end of processing that exception and no handler marked it as handled, then we need to move to the wrapper, and so on.

When handling a single exception in the stack, we then notify the handlers in a particular order. That order works breadth-first for handlers marked as such, then depth-first, which is the default phase (or mode) in which handlers get registered.

One way to think of the handler notification order is to think of them as JSF phase listeners, where the "before" is a super-type handler marked TraversalMode.BREADTH_FIRST and the "after" is a super-type handler marked TraversalMode.BREADTH_FIRST. Obviously, the actual even is the invocation of the handler for the specific type (which may not exist, btw).  
  
> change terminology for exception type hierarchy traversal
> ---------------------------------------------------------
>
>                 Key: SEAMCATCH-31
>                 URL: https://issues.jboss.org/browse/SEAMCATCH-31
>             Project: Seam Catch
>          Issue Type: Feature Request
>          Components: Core API
>    Affects Versions: Alpha2
>            Reporter: Dan Allen
>            Assignee: Jason Porter
>             Fix For: Alpha3
>
>
> There appears to be some confusion about what the traversal path means. We've come up with some better terms that should help users understand how to use it.
> When one of the exceptions in the stack trace is being handled, the handlers for that exception are notified in a particular order. That order is based on the type hierarchy of the exception. The traversal seeks to address this scenario:
> Assume that a group of exceptions have a common super class. You may choose to write a handler that catches all of those exceptions by handling that super type. We'll call that a category handler, where the super class represents a category (i.e., SQLException) So the question you have to ask yourself, then, is: 
> Do you want your category handler to be notified before or after the handler for the subtype gets notified?
> You specify you want the category handler to be notified before by adding the attribute during = TraversalPath.DESCENDING to the @Handles exception.
> However, this descending/ascending isn't catching on. Tree traversal is more commonly referred to using the terms breadth-first or depth-first. Catch notifies breadth-first handlers before depth-first handlers, in the order of the tree traversal (walking the exception type hierarchy).
> Therefore, these attribute values would make more sense:
> during = TraversalMode.BREADTH_FIRST
> during = TraversalMode.DEPTH_FIRST (default)
> If you write a SQLException handler with during = TraversalMode.BREADTH_FIRST, then it will be notified before a handler for BatchUpdateException.  

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira