sotretus
Aug 29th, 2007, 09:26 AM
Here are some more thoughts on this topic.
Dave,
I still think the exception Handler should be (at least) inside the repeat cycle. If the RepeatInterceptor is the way to go then I would suggest creating an (abstract or 'composable', or final, etc.) ExceptionHandlerInterceptor that implements all unrequired methods for an Exception Handler and make them final, namely:
* before
* open
* onError
* close
It should also implement the 'after' method to analyze if the Result was a Throwable or an ExitStatus, and only delegate if it is a Throwable. (Actually, this is what we finally ended up doing in our particular case, where we wanted to manage in one place and in the same way exceptions thrown both from the ItemProvider and ItemProcessor). In this line of thought, it should provide a method for subclasses (or for ExceptionHandler implementors, if it is "composed of an ExceptionHandler") that receives the Throwable and not a (generic) Object.
(Notice that this *would* allow to remove the "ExceptionHandler" interface altogether, since the RepeatInterceptor's onError method is called after iterating, for every exception thrown. So this could be an enhancement of the before mentioned ExceptionHandlerInterceptor, and we could have the possibility to handle exceptions outside the loop, or inside the loop. From this base class it should be straightforward to create two branches, one for only handling iteration exceptions and the other one for handling after-iteration exceptions (of course, the 'mixed' case is supported by the base class).
WDYT?
Dave,
I still think the exception Handler should be (at least) inside the repeat cycle. If the RepeatInterceptor is the way to go then I would suggest creating an (abstract or 'composable', or final, etc.) ExceptionHandlerInterceptor that implements all unrequired methods for an Exception Handler and make them final, namely:
* before
* open
* onError
* close
It should also implement the 'after' method to analyze if the Result was a Throwable or an ExitStatus, and only delegate if it is a Throwable. (Actually, this is what we finally ended up doing in our particular case, where we wanted to manage in one place and in the same way exceptions thrown both from the ItemProvider and ItemProcessor). In this line of thought, it should provide a method for subclasses (or for ExceptionHandler implementors, if it is "composed of an ExceptionHandler") that receives the Throwable and not a (generic) Object.
(Notice that this *would* allow to remove the "ExceptionHandler" interface altogether, since the RepeatInterceptor's onError method is called after iterating, for every exception thrown. So this could be an enhancement of the before mentioned ExceptionHandlerInterceptor, and we could have the possibility to handle exceptions outside the loop, or inside the loop. From this base class it should be straightforward to create two branches, one for only handling iteration exceptions and the other one for handling after-iteration exceptions (of course, the 'mixed' case is supported by the base class).
WDYT?