The original use case was to handle the exception at a higher hierarchy level before diving down to the actual implementing class of the exception. Say I want to log all Exceptions, but PersistenceExceptions also need to be retried or have special logging to tie them to a DB exception. @Handles starts at the lowest class level and goes up the chain, @BeforeHandles goes the opposite way. Maybe it would make sense to add a new type in there so you can't do things in a @BeforeHandles handler that you can in a @Handler, or maybe it's a documentation thing.
On Sat, Jul 5, 2014 at 4:17 PM, Gerhard Petracek <[email protected] > wrote: > hi jason, > > so far we don't have tests for it, because i don't like the current > approach and we should re-visit that part of exception-control. > imo we have one big use-case we don't support in a nice manner: > "read-only" exception observers in addition to handlers. the annotation > @BeforeHandles sounds like it, but in the end it's handled like @Handles > just one step earlier. > i'm not sure about the original use-case, but imo there is no real benefit > in case of @BeforeHandles compared to @Handles + ordinal. > > regards, > gerhard > > > > 2014-07-05 20:22 GMT+02:00 Jason Porter <[email protected]>: > > > Do we have tests for 636? If we don't have a test we need to create one > so > > I understand how we can best fix this problem. — > > Sent from Mailbox > -- Jason Porter http://en.gravatar.com/lightguardjp
