6:07 p.m.
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
Reporter: Dan Allen
Assignee: Jason Porter
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
6:07 p.m.
New subject: [JBoss JIRA] Updated: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Dan Allen updated SEAMCATCH-31:
-------------------------------
Fix Version/s: Alpha3
Affects Version/s: Alpha2
Component/s: Core API
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
10:56 a.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Jozef Hartinger commented on SEAMCATCH-31:
------------------------------------------
IMHO these are two different things.
Currently, the ASCENDING/DESCENDING setup controls the order of handlers based on the
exception chain. According to the docs there are two phases during exception handling
(http://docs.jboss.org/seam/3/catch/latest/reference/en-US/html/client_usa...)
DESCENDING - where the chain is being traversed from the outer most exception to the root
cause
ASCENDING - where the same chain is being traversed from the root cause to the outer most
exception
for every exception in the chain, handlers for supertypes of the exception are called
(depth first)
IMHO your proposal changes the semantics of traversal mode. It removes the chain
traversing completely (it is traversed only once) and it uses the traversal mode to
control the order in which handlers for different types of an exception type tree are
called.
To ilustrate:
3SS
|
3S
|
3 --> 2 --> 1
3SS is a superclass of 3S
3S is a superclass of 3
3 is caused by 2
2 is caused by 1
So far the traversal mode controlled the horizontal axis. I think that what you propose
modifies it to control the vertical axis.
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
1:07 p.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Dan Allen commented on SEAMCATCH-31:
------------------------------------
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 process that whole
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 are called.
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
1:07 p.m.
New subject: [JBoss JIRA] Issue Comment Edited: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
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 even 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 are called.
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
1:07 p.m.
New subject: [JBoss JIRA] Issue Comment Edited: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Dan Allen edited comment on SEAMCATCH-31 at 12/17/10 2:06 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 are called.
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).
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 process that whole
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 are called.
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
1:09 p.m.
New subject: [JBoss JIRA] Issue Comment Edited: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
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
12:05 a.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Jason Porter commented on SEAMCATCH-31:
---------------------------------------
Everyone good with this proposed change?
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
10:30 a.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Dan Allen commented on SEAMCATCH-31:
------------------------------------
I'm in for it (obviously :))
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
6:12 a.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Jozef Hartinger commented on SEAMCATCH-31:
------------------------------------------
I'm fine with it.
Just wanted to point out that with these changes we are dropping the "2-way
pass" of the exception chain so that everybody is aware. We can probably live without
that.
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
1:37 p.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Dan Allen commented on SEAMCATCH-31:
------------------------------------
Yep. This is also consistent w/ the behavior in Seam 2 (though Catch is far more
thorough).
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
9:22 a.m.
New subject: [JBoss JIRA] Commented: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Jason Porter commented on SEAMCATCH-31:
---------------------------------------
Implemented change
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: 3.0.0.Alpha2
Reporter: Dan Allen
Assignee: Jason Porter
Fix For: 3.0.0.Alpha4
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
9:22 a.m.
New subject: [JBoss JIRA] Resolved: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Jason Porter resolved SEAMCATCH-31.
-----------------------------------
Resolution: Done
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: 3.0.0.Alpha2
Reporter: Dan Allen
Assignee: Jason Porter
Fix For: 3.0.0.Alpha4
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
2 p.m.
New subject: [JBoss JIRA] Closed: (SEAMCATCH-31) change terminology for exception type hierarchy traversal
[
https://issues.jboss.org/browse/SEAMCATCH-31?page=com.atlassian.jira.plug...
]
Jason Porter closed SEAMCATCH-31.
---------------------------------
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: 3.0.0.Alpha2
Reporter: Dan Allen
Assignee: Jason Porter
Fix For: 3.0.0.Alpha4
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
5584
days inactive
5601
days old
13 comments
3 participants
participants (3)
-
Dan Allen (JIRA) -
Jason Porter (JIRA)
-
Jozef Hartinger (JIRA)