Nice way of executing generic code blocks in same wrapping context supporting java.lang.Exception with no in/out params?

Question

I was looking for a solution like this:
(in more detail: for some maven plugin running different build code in several phases/goals):

  void foo() {

    execCode( () -> doBar() ) ;
    execCode( () -> new File("/baz.txt").create() ) ;
    execCode( () -> { 
      System.out.println( "test" ) ; 
      throw new MojoFailureException("problem 1") ; 
    }) ;
  }


  void execCode( Code code ) throws MojoFailureException {

    try {

      // ... some common initialization / param parsing here ...

      code.run() ;

    } catch( Exception e ) {

      // ... common exception handling throwing e.g. MojoFailureException ...
    }
  }

supporting (primarily (E), (G) and (S) below):

• (E): the code blocks throwing any java.lang.Exception
• (V): no in or out values/objects needed
• (S): short, easy to read/write code (minimal clutter)
  • also avoiding IDE warnings and dealing with it (e.g. via @Ignore for unused generic type parameters)
• (8): Java 8+ support
• (L): no further lib/jar dependencies, if possible (very common ones like Google Guava or Apache Commons would be fine as well)
• (G): generic context (e.g. some build tasks) where it is fine to just know, that something should/will be done, but the proper exception handling and other stuff (common to each call) should be encapsulated

Answer 1

best found strategy in short:

import java.util.concurrent.Callable;

// ...

  void foo() {

    execCode( () -> doBar() ) ;
    execCode( () -> 5 + 2 ) ;
    execCode( () -> { System.out.println( "test" ) ; return 0 ; }) ;
  }


  void execCode( Callable<Object> code ) {

    try {

      code.call() ;

    } catch( Exception e ) {

      // ...
    }
  }

more details:

solutions partially found in other answers and their disadvantages for above:

• (S.L): using java.util.concurrent.Callable (above solution)
  • fulfills all above requirements
  • would also nicely work with some return value, if needed
• (S.F): using java.util.Function
  • does not support (E)
  • especially with (V) it's more clutter ((S)) and semantically confusing
  • e.g. void foo() { execCode( (i) -> doBar() ) ... void execCode( Function< Void, Void > code ) { ... code.apply( null ) ... }
  • see also this answer
• (S.I): creating some custom interface (class) to accomplish it
  • contradicts (S)
  • e.g. interface Code { abstract void run() throws Exception; }
  • see also this answer
• (S.M): using method references like this::doBar
  • special case which may be very short and elegant if the code is (already) in some objects method contributing to (S)
  • would work with execCode( Callable<Object> ... ) { ... }
  • but not with execCode( Runnable ... ) { ... }
    • contradicts (E)
  • see also this answer
• (S.R): using java.lang.Runnable
  • contradicts (E) and thus (S) since it would only allow to throw RuntimeException but no checked ones
  • see also this answer
• (S.A): using java.lang.AutoCloseable
  • it matches the (E), (V) and (L) requirements, but it needs at least some comments to explain, why there is a execCode( AutoCloseable code ) { ... code.close() ; ... } although the code does not have to do anything with a semantic closing context :)
• (S.C): using java.util.function.Consumer
  • does not support (E)
  • see also this answer* (S.X): using java.lang.reflect.Method
  • would contradict especially (S)
  • see also this answer
• (S.7): command pattern solution
  • if it must be Java 7- compatible (contradicting (8)) this answer with the command pattern may be some good solution