8

I have good number of Service and DAO classes which has the same set of 30 line exception code block which gets repeated and it shows up in Code Duplication report.

The approach which I can think of is to

  • Extract the common exception code blocks to a common method and call
    the method in one shot

    Re-organize the methods to ensure there is always one entry and exit point to Services or DAOs which will have just one set of exception code.

Are there any better ways to approach this scenario?

Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
dosakiller
  • 91
  • 1
  • 1
  • 2
  • 2
    please post a snippet of code as an example of what these blocks typically contain – gnat Jan 28 '13 at 13:14
  • 2
    I don't think you can do any better. Scala allows you to abstract over exception handlers (basically, an exception handler is just an object which conforms to a specific interface, so you can create an object with the semantics you want and just pass it as a handler anywhere you need those semantics), but AFAIK Java doesn't have anything similar. – Jörg W Mittag Jan 28 '13 at 13:30

2 Answers2

5

Extract the exception handling into a method:

public interface Action {
    public void execute() throws ...;
}

public static void handleErrors(Action action) throws ... {
   try {
      // setup .....
      action.execute();
   } catch (...) {
      // ...
   } finally {
      // cleanup ...
   }
}

Then call it like this:

handleErrors(new Action(){ public void execute() throws ... {
    // ...
}});

The syntax is ugly, but it's still much better than duplicating the error handling dozens of times. Anytime you are duplicating more than a couple of lines, you should stop and figure out how to avoid that duplication. In Java, this often means using interfaces and anonymous classes to pass one block of code to run inside some common control logic. The same technique can be reused to eliminate duplicated looping code.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
  • 3
    lack of delegates really adds bloat in this example. Not trying to start trouble; just documenting the fact that while this is the best solution, it's a bit more natural in other languages. – brian Feb 05 '13 at 18:05
  • @brian: yes, this is easier in almost every other modern programming language. – kevin cline Feb 05 '13 at 23:48
  • Doesn't this mean that you will have to throw generic exceptions in the `throws` clause of `handleErrors` which may not be specific enough for client code, and also catch a whole lot of possible exceptions in the try-catch block? Doesn't it also mean that the exception recovery code will have to accomodate for potentially different situations possibly leading to many `ifs` or `switches` ? – Tulains Córdova Apr 21 '17 at 14:21
  • 1
    It's worth noting that as of Java 8 this can be written much more cleanly. Specifically, the Action interface is no longer required. – JimmyJames Apr 21 '17 at 14:52
  • @TulainsCórdova Presumably if the cleanup block is the same for everything, the exceptions are known. Since this is a DOA, I mean DAO design it's likely there is no business logic in this part of the code and every exception is either IO or SQL and it won't matter which type you are working with. – JimmyJames Apr 21 '17 at 15:17
  • 1
    Another possible answer that didn't exist in 2013 is to use a default method on an interface to hold this common logic. I'm not sure if this is a good idea or not since this feature changes semantics of what an interface is in Java in a really fundamental way. – JimmyJames Apr 21 '17 at 15:19
0

Consider building an explicit exception handler.

It's a similar approach as your first suggestion but places the methods within an object instead. It's also similar to older, monolithic applications that had dedicated interrupt handlers. Either way, the point is the same - write the handling code once and then call as needed.