[seam-issues] [JBoss JIRA] Commented: (SEAMCATCH-4) Include the ability to filter stack traces

[Dan Allen (JIRA)]

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

Dan Allen commented on SEAMCATCH-4:
-----------------------------------

Some discussion that led to the proposed API:

(11:42:06) Dan: I realized that if we had something like a PrepareCaughtException event
(11:42:20) Dan: then in that event, it would be possible to apply filtering or mapping
(11:42:25) Dan: and then do
(11:42:33) Dan: PrepareCaughtException#setException()
(11:42:43) Dan: just like ProcessAnnotatedType#setAnnotatedType()
(11:43:12) Dan: so that's one place to do global filtering, and is interesting because then you actually pare down the exception that even needs to be handled
(11:43:20) Dan: potentially, as an option
(11:43:30) Jason: Cool idea
(11:43:40) Dan: or you can replace causes w/ an app equivalent
(11:43:55) Dan: for instance persistence can provide some mappings between a SQLExeption and something like InvalidTableException
(11:44:00) Dan: and so forth
(11:44:23) Jason: That would basically handle your mapping
(11:44:28) Dan: then, you could always use the same api for filtering the exception at any time, since it's reusable
(11:44:30) Dan: yep
(11:44:32) Dan: exactly
(11:44:53) Dan: I was thinking whether we needed a post-process
(11:44:57) Jason: What would that event need on it?
(11:44:59) Dan: maybe let's wait to see if there is some need
(11:45:14) Dan: I'm thinking it just has the Exception
(11:45:17) Jason: We fire it once?
(11:45:23) Dan: and the unwrapped stack
(11:45:26) Jason: At the start of catch process?
(11:45:33) Dan: yes
(11:45:35) Dan: yes
(11:46:01) Dan: I thought about ProcessCaughtException, but I don't like how that implies handling
(11:46:07) Dan: I like Prepare
(11:46:10) Dan: or PreProcess
(11:46:21) Dan: this is really interesting
(11:46:30) Dan: it totally changes the game
(11:46:36) Dan: because we are saying, not only do you have these handlers
(11:46:51) Dan: and do they get to deal with the exception causes individually (like a handler for SQLException)
(11:47:02) Dan: but you can tune the exception getting fed into the system
(11:47:06) Dan: I'd even say
(11:47:09) Dan: you could add qualifiers
(11:47:32) Dan: btw, the qualifiers should be available to the CaughtExeption, I was thinking about that
(11:47:34) Dan: if they aren't already
(11:47:49) Dan: something imo missing from the eventing system in cdi
(11:47:57) Jason: hm?
(11:48:01) Jason: which qualifiers?
(11:48:19) Dan: consider this...your observer is called
(11:48:26) Dan: in our case handlers, but I'm going to talk in general
(11:48:31) Dan: you don't really know why
(11:48:47) Dan: you know because it at least had a subset of qualifiers, or matched any
(11:49:00) Dan: but you don't know what qualifiers were actually on the original event
(11:49:12) Dan: we can provide that info in CaughtException
(11:49:30) Jason: Ah
(11:49:42) Dan: just some info...why not share it
(11:49:53) Dan: I think this is solved in CDI
(11:50:00) Dan: by allowing you to inject the Event object
(11:50:11) Dan: when you observe...so like this
(11:50:40) Dan: @Observes(@Updated Document document, Event<Documentg firingEvent)
(11:50:44) Dan: interesting for two reasons
(11:51:00) Dan: one, you have access to information about the firing
(11:51:08) Dan: you can turn around and fire the event again
(11:51:47) Jason: true
(11:51:49) Dan: rats, Event doesn't have getQualifiers() on it
(11:51:51) Jason: But then you'll be called again
(11:51:52) Dan: it probably should
(11:51:56) Dan: well, likely
(11:52:07) Dan: you would use it as a parent, add a qualifier and go again, something like that
(11:52:14) Dan: kind of as a pass on
(11:52:25) Dan: I don't know...you could also just have this
(11:52:28) Dan: EventSource
(11:52:37) Dan: EventSource { qualifiers, bean }
(11:53:02) Dan: anyway, for us, we just expose it from CaughtException
(11:53:28) Dan: but that's a side note
(11:53:36) Dan: back to the pre-processor
(11:53:49) Dan: ah, I had an idea about the statelessness of the filter
(11:54:02) Dan: the key here is not providing the index or anything
(11:54:15) Dan: but providing a state object
(11:54:29) Dan: or, a status object, not sure the correct term
(11:54:39) Dan: a visitlog
(11:54:49) Dan: and it has like last frame
(11:54:54) Dan: you can set a mark
(11:54:59) Dan: maybe a fold marker
(11:55:05) Dan: things like that
(11:55:08) Dan: then you can say like
(11:55:37) Dan: visitlog.isMarkSet()
(11:55:46) Dan: or getMarkedFrame()
(11:56:00) Dan: that way, the range information is provided to the method
(11:56:24) Jason: Hm
(11:56:35) Jason: We'd need a reset or something
(11:56:41) Dan: so let me give you the api I'm thinking
(11:56:45) Jason: And they could also give us the replace info
(11:56:49) Dan: yeah ;)
(11:56:51) Dan: exactly
(11:56:53) Dan: like this
(11:56:57) Dan: visitlog.replaceFrame()
(11:57:07) Dan: and then you still return a result
(11:57:27) Dan: like SKIP, CONTINUE, TERMINATE

> Include the ability to filter stack traces
> ------------------------------------------
>
>                 Key: SEAMCATCH-4
>                 URL: https://issues.jboss.org/browse/SEAMCATCH-4
>             Project: Seam Catch
>          Issue Type: Feature Request
>            Reporter: Jason Porter
>            Assignee: Jason Porter
>             Fix For: 3.0.0.Alpha4
>
>
> Catch should draw from ideas such as:
> - http://www.docjar.org/html/api/org/apache/commons/lang/exception/NestableDelegate.java.html
> - http://stackoverflow.com/questions/2504647/bash-how-to-filter-java-exception-info
> - http://squirrelsewer.blogspot.com/2010/03/filter-your-stack-traces.html
> - http://pastebin.com/p8aCSeuu

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