Announcement Announcement Module
No announcement yet.
Exception Handling (BATCH-69) Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Exception Handling (BATCH-69)

    Here are some more thoughts on this topic.


    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).


  • #2
    The ExceptionHandler is there for a specific reason and (notwithstanding the difficulty to configure it while BATCH-69 is still open) I don't see a reason to replace it completely. A special purpose RepeatInterceptor might be a good idea - open a JIRA for it and we'll get round to that sometime soonish. I think Lucas understands your use case in a bit more detail so he might also want to comment (here or in JIRA).


    • #3

      I'm sure it is useful, and I am not suggesting to eliminate it, but to enhance it. Just to allow the use of an ExceptionHandler inside the repeat operations. I just mentioned some thoughts on how this could be done, but the important thing is the idea.


      • #4
        Great, then thanks again. I want to bake the idea into a dev plan, and I'm happy to log it in JIRA myself. I'm just about to go on vacation, so if I don't get round to it, remind me in a couple of weeks (or just log it yourslef and don't expect an immediate reply).