How to not repeat code within catch blocks?

Question

I am having a hard time not to repeat myself in a Java program I am working on at the moment.

Say, I need to declare a lot of methods that basically are structured in the following way:

public SomeEntity doSomething (String someAttribute, String anotherAttribute) {
    EntityManager em = this.createEntityManager();

    EntityTransaction tx = null;
    try {

        /*
         * ... independent logic ...
         */

        tx = em.getTransaction();
    } catch (RuntimeException e) {
        if (tx != null && tx.isActive()) { 
            tx.rollback();
        }
        throw e;
    } finally {
        em.close();
    }

    return something;
}

The method body of all methods needs to contain theses elements for resource management.

The "independent logic" itself will be rather complex too, so putting the try/catch statement in a separate method won't really work.

I want to avoid to repeat this code. What are the best practices to apply in these situations?

Answer 1

Create an interface:

public interface EntityManagerAction {
   public void execute(EntityManager em);
}

And a utility class:

public class EntityUtil {
  public static void executeWithEntityManager(EntityManagerAction action) {
    EntityManager em = someHowCreateEntityManager();

    EntityTransaction tx = null;
    try {
        action.execute(em);
        tx = em.getTransaction();
    } catch (RuntimeException e) {
        if (tx != null && tx.isActive()) { 
            tx.rollback();
        }
        throw e;
    } finally {
        em.close();
    }
  }
}

Now you can re-use the boiler-plate in the EntityUtil class, and your code becomes:

public SomeEntity doSomething (String someAttribute, String anotherAttribute) {
   Something something; 
   EntityUtil.executeWithEntityManager(new EntityManagerAction() {
        public void execute(EntityManager em ) {

        /*
         * ... independent logic ...
         */
         //use the passed in 'em' here.
        }
    });

    return something;
}

See also What is the "Execute Around" idiom?

Answer 2

If all your finally clauses are used to close Streams and such (anything that implements AutoCloseable), you can use try-with-resources (as suggested in one of the comments) to get rid of the finally clause.

However, if you need a more generic solution, and have the same type of Exceptions caught and the same sort of handling in the finally clause, you can create an abstract class such as:

abstract class SensitiveBlockHandler {
    public void handle() {
        try {
            doHandling();
        } catch (SomeException | AnotherException e) {
            // TODO: handle exceptions here ...
        } finally {
            // TODO: cleanup here ...
        }
    }

    protected abstract void doHandling();
}

Then, you can create inner classes to handle the different situations, either as anonymous classes or not. The code should look something like:

public SomeEntity doSomething (String someAttribute, String anotherAttribute) {
    new SensitiveBlockHandler() {
        protected void doHandling() {
            /*
             * ... independent logic ...
             */
        }
    }.handle();

    return something;
}

Answer 3

I would create a abstraction of the independent logic, say Job, and the doSomething() will become processJob() in a Service class. The you will be calling your processJob() for every processing and the all the code from your example except the independent logic will be written exactly once.

Edit: Which is what nos suggested in comment: What is the "Execute Around" idiom?

Answer 4

We recently faced an issue like this, and decided to go with the callback design pattern.

So, if all of the methods have similar code and it's just the independant logic that is different, you could create an interface whose implementations handle the independent code. So something like this:

public SomeEntity doSomething (String someAttribute, String anotherAttribute) {
       return (SomeEntity)callbackMethod(someAttribute, anotherAttribute, new IndependentCodeInterfaceImpl1());
}

public SomeOtherEntity doSomethingElse (String someAttribute, String anotherAttribute) {
    return (SomeOtherEntity)callbackMethod(someAttribute, anotherAttribute, new IndependentCodeInterfaceImpl2());
}

private Object callbackMethod(String someAttribute, String anotherAttribute, IndependentCodeInterface independent) {
    EntityManager em = this.createEntityManager();
    EntityTransaction tx = null;
    Object response = null;
    try {
        response = independent.execute(someAttribute, anotherAttribute, em);
        tx = em.getTransaction();
    } catch (RuntimeException e) {
        if (tx != null && tx.isActive()) { 
            tx.rollback();
        }
        throw e;
    } finally {
        em.close();
    }
    return response;
}

Answer 5

If you are using a JavaEE application server than your code can be simplified dramatically by using a stateless session bean:

@Stateless
public class SomethingFactory {

    @PersistenceContext
    private EntityManager em;

    public SomeEntity doSomething (String someAttribute, String anotherAttribute) {
       /*
        * ... independent logic ...
        */
       return something;
    }

}

The container will look after all the transaction management semantics for you.

Answer 6

you can make your method signatures return the exception

 public SomeEntity doSomething (String someAttribute, String anotherAttribute) throws RuntimeException {
// your independent logic
}

 public SomeEntity doSomethingElse (String someAttribute, String anotherAttribute) throws RuntimeException {
// your independent logic
}

 public SomeEntity doSomethingDifferent (String someAttribute, String anotherAttribute) throws RuntimeException {
// your independent logic
}

then you can handle it in a seperate method:

   public String yourHandleMethod(){
String something = "";
EntityManager em = this.createEntityManager();

    EntityTransaction tx = null;
try{
 doSomething();
 doSomethingElse();
 doSomethingDifferent();
 tx = em.getTransaction();
    } catch (RuntimeException e) {
        if (tx != null && tx.isActive()) { 
            tx.rollback();
        }
        throw e;
    } finally {
        em.close();
    }

    return something;

Answer 7

You can implement a mechanism similar to Spring Transaction Template.

First, implement a callback which will be implemented for each business operation, providing both the entity manager and transaction:

public static interface TransactionCallback<R> {
  R doInTransaction(EntityManager em, EntityTransaction tx);
}

Then, create a generic method with the boilerplate code:

public <T> T execute(TransactionCallback<T> callback) {
  EntityManager em = this.createEntityManager();
  EntityTransaction tx = null;

  try {
    tx = em.getTransaction();
    return callback.doInTransaction(em, tx);
  } catch (RuntimeException e) {
    if (tx != null && tx.isActive()) { 
        tx.rollback();
    }
    throw e;
  } finally {
    em.close();
  }
}

Finally, you can create business logic similar to this:

public SomeEntity doSomething(String someAttribute, String anotherAttribute) {
  return execute(new TransactionCallback<SomeEntity>() {
    @Override
    public SomeEntity  doInTransaction(EntityManager em, EntityTransaction tx) {
      // do something here
    }
  });
}

This approach have several advantages. It is clean and you can intercept all actions on one place - for example: add logging, etc.

I am sorry for any syntax errors, I am writing it without IDE. But you get the idea.

EDIT: Maybe it can be shorter using lambdas in JDK 8, because TransactionCallback might be functional interface :).

Answer 8

For completeness - there's the Template Method Pattern. It allows you to abstract all of the management code out of a procedure and just implement the core function. This pattern is especially useful when you have a number of meta-requirements such as closing stuff while correctly handling exceptions.

I use this pattern for, among other things, running database queries because of all of the rules about being sure to close all ResultSets and Connections while still correctly managing PreparedStatements.

abstract class DoSomethingWithEntity {

    public SomeEntity doSomething(String someAttribute, String anotherAttribute) {
        SomeEntity something;
        EntityManager em = createEntityManager();

        EntityTransaction tx = null;
        try {
            tx = em.getTransaction();
            // Call the abstract stuff that can be different.
            something = doIt(em, tx);
        } catch (RuntimeException e) {
            if (tx != null && tx.isActive()) {
                tx.rollback();
            }
            throw e;
        } finally {
            em.close();
        }

        return something;
    }

    // The bit you want to write yourself. Make it abstract so you have to write it.
    abstract SomeEntity doIt(EntityManager em, EntityTransaction tx) throws Exception;
}

public void test() {
    SomeEntity e = new DoSomethingWithEntity() {

        @Override
        SomeEntity doIt(EntityManager em, EntityTransaction tx) {
            // Do your stuff here.
            return new SomeEntity();
        }

    }.doSomething("someAttribute", "anotherAttribute");
}

Note that you don't have to make all exceptions into RuntimeException - you can define explicitly what exceptions are allowed to be thrown.

Answer 9

FYI - the new lambda expressions feature in JDK 1.8 is now the most elegant way to solve this problem. Your DoSomething method would just be something like this:

DataExecutor.execute(() -> {
    // let's say your "independent logic" is the following three statements
    statementA;
    statementB;
    statementC;
});

Your DataExecutor.execute method would look something like this (you'll maybe want a return type):

public static void execute(work)
{
    EntityManager em = this.createEntityManager();

    EntityTransaction tx = null;
    try {

        // this is the "independent logic" you passed in via the "work" lambda
        work.doWork();

        tx = em.getTransaction();
    } catch (RuntimeException e) {
        if (tx != null && tx.isActive()) { 
            tx.rollback();
        }
        throw e;
    } finally {
        em.close();
    }

And lastly, you'll need to define a (or use an existing) functional interface:

@FunctionalInterface
public interface DataFuncVoid {
    public abstract void doWork();
}