¿Cuál es la mejor manera de manejar una excepción de ejecución?

Aquí hay un par de información interesante para las Excepciones verificadas y contra las verificadas. Discusión de Brian Goetz y un argumento contra excepciones verificadas de Discusión de Eckel . Pero yo no sabía si usted ya ha implementado y dado un pensamiento sobre el refactor de excepción comprobado que se discute por Josué en este libro.

De acuerdo con las perlas de Java Efectivas, uno de los métodos preferidos de manejo de excepciones verificadas es convertir una excepción en una excepción no comprobada. Así, por ejemplo,

try{
obj.someAction()
}catch(CheckedException excep){
}

Cambie esta implementación a

if(obj.canThisOperationBeperformed){
obj.someAction()
}else{
// Handle the required Exception.
}

Me temo que no hay respuesta a su problema. Básicamente, está lanzando una tarea en un hilo diferente al que está en, y desea usar el patrón ExecutorService para capturar todas las excepciones que la tarea puede lanzar, más la ventaja de interrumpir esa tarea después de una cierta cantidad de tiempo. Su enfoque es el correcto : no podría hacer eso con un Runnable desnudo.

Y esta excepción, de la que no tiene información, desea lanzarla de nuevo, con un cierto tipo : ProcessExecutionException, InterruptedException o IOException. Si es otro tipo, desea repensarlo como una excepción de RuntimeException (que por cierto no es la mejor solución, ya que no cubre todos los casos).

Así que tienes un impendance mismatch allí : un Lanzable por un lado, y un tipo de excepción conocido por el otro. La única solución que tienes que resolver es hacer lo que has hecho: comprobar el tipo, y lanzarlo de nuevo con un molde. Se puede escribir de manera diferente, pero se verá igual en final...

Esto es lo que hago en esta situación. Esto logra lo siguiente:

• Vuelve a lanzar excepciones marcadas sin envolverlas
• Pega las trazas de la pila

Código:

public <V> V waitForThingToComplete(Future<V> future) {
    boolean interrupted = false;
    try {
        while (true) {
            try {
                return future.get();
            } catch (InterruptedException e) {
                interrupted = true;
            }
        }
    } catch (ExecutionException e) {
        final Throwable cause = e.getCause();
        this.prependCurrentStackTrace(cause);
        throw this.<RuntimeException>maskException(cause);
    } catch (CancellationException e) {
        throw new RuntimeException("operation was canceled", e);
    } finally {
        if (interrupted)
            Thread.currentThread().interrupt();
    }
}

// Prepend stack frames from the current thread onto exception trace
private void prependCurrentStackTrace(Throwable t) {
    final StackTraceElement[] innerFrames = t.getStackTrace();
    final StackTraceElement[] outerFrames = new Throwable().getStackTrace();
    final StackTraceElement[] frames = new StackTraceElement[innerFrames.length + outerFrames.length];
    System.arraycopy(innerFrames, 0, frames, 0, innerFrames.length);
    frames[innerFrames.length] = new StackTraceElement(this.getClass().getName(),
      "<placeholder>", "Changed Threads", -1);
    for (int i = 1; i < outerFrames.length; i++)
        frames[innerFrames.length + i] = outerFrames[i];
    t.setStackTrace(frames);
}

// Checked exception masker
@SuppressWarnings("unchecked")
private <T extends Throwable> T maskException(Throwable t) throws T {
    throw (T)t;
}

Parece funcionar.

No estoy seguro de por qué tienes el bloque if/else en la captura y instanceof, creo que puedes hacer lo que quieras con: -

catch( ProcessExecutionException ex )
{
   // handle ProcessExecutionException
}
catch( InterruptException ex )
{
   // handler InterruptException*
}

Una cosa a considerar, para reducir el desorden, es capturar la excepción dentro de su método llamable y volver a lanzar como su propia excepción o excepciones específicas de dominio/paquete. La cantidad de excepciones que necesita crear dependerá en gran medida de cómo su código de llamada responderá a la excepción.

El javadoc de java.util.concurrent.Future.get() establece lo siguiente. Entonces, ¿por qué no simplemente captura ExecutionException (y Cancelación e Interrumpida según lo declarado por el método java.util.concurrent.Future.get())?

...
Lanza:

CancellationException - si el cálculo fue cancelado

ExecutionException-si el cálculo arrojó una excepción

InterrumpedException-si el hilo actual se interrumpió mientras esperando

Así que básicamente puedes lanzar cualquier excepción dentro de tu callable y simplemente atrapar ExecutionException. Entonces ExecutionException.getCause()mantendrá la excepción real de su lanzamiento invocable como se indica en el javadoc. De esta manera está protegido de los cambios de firma de método relacionados con la declaración de excepción marcada.

Por cierto, nunca debes atrapar Throwable, ya que esto también atraparía RuntimeExceptions y Errors. Catching Exception es un poco mejor, pero aún no se recomienda, ya que atrapará RuntimeExceptions.

Algo como:

               try {

                    MyResult result = myFutureTask.get();
                } catch (ExecutionException e) {
                    if (errorHandler != null) {
                        errorHandler.handleExecutionException(e);
                    }
                    logger.error(e);
                } catch (CancellationException e) {
                    if (errorHandler != null) {
                        errorHandler.handleCancelationException(e);
                    }
                    logger.error(e);

                } catch (InterruptedException e) {
                    if (errorHandler != null) {
                        errorHandler.handleInterruptedException(e);
                    }
                    logger.error(e);
                }

En la clase que llama, captura el Throwable último. Por ejemplo,

try{
    doSomethingWithTimeout(i);
}
catch(InterruptedException e){
    // do something
}
catch(IOException e){
    // do something
} 
catch(TimeoutException e){
    // do something
}
catch(ExecutionException e){
    // do something
}
catch(Throwable t){
    // do something
}

Y el contenido de doSomethingWithTimeout(int timeout) debería verse así,

.
.
.
ExecutorService service = Executors.newSingleThreadExecutor();
try {
    Future<byte[]> future = service.submit( callable );
    return future.get( timeout, TimeUnit.MILLISECONDS );
} 
catch(Throwable t){
    throw t;
}
finally{
    service.shutdown();
}

Y su firma de método debería verse como,

doSomethingWithTimeout(int timeout) throws Throwable

Aquí hay otra manera de hacerlo, aunque no estoy convencido de que esto sea menos torpe o menos propenso a romper que hacerlo con una instancia de verificación como en su pregunta:

public static byte[] doSomethingWithTimeout(int timeout)
        throws ProcessExecutionException, InterruptedException, IOException, TimeoutException {
    ....
    try {
        ....
        return future.get(1000, TimeUnit.MILLISECONDS);
        .....
    } catch (ExecutionException e) {

        try {
            throw e.getCause();
        } catch (IOException ioe) {
            throw ioe;
        } catch (InterruptedException ie) {
            throw ie;
        } catch (ProcessExecutionException pee) {
            throw pee;
        } catch (Throwable t) {
            //Unhandled exception from Callable endups here
        }

    } catch (TimeoutException e) {
        throw e;
    } catch.....
}

No diría que recomiendo esto, pero aquí hay una manera de hacerlo. Es seguro para el tipo y quienquiera que venga a modificarlo después de usted probablemente no estará satisfecho con él.

public class ConsumerClass {

    public static byte[] doSomethingWithTimeout(int timeout)
            throws ProcessExecutionException, InterruptedException, IOException, TimeoutException {
        MyCallable callable = new MyCallable();
        ExecutorService service = Executors.newSingleThreadExecutor();
        try {
            Future<byte[]> future = service.submit(callable);
            return future.get(timeout, TimeUnit.MILLISECONDS);
        } catch (ExecutionException e) {
            throw callable.rethrow(e);
        } finally {
            service.shutdown();
        }
    }

}

// Need to subclass this new callable type to provide the Exception classes.
// This is where users of your API have to pay the price for type-safety.
public class MyCallable extends CallableWithExceptions<byte[], ProcessExecutionException, IOException> {

    public MyCallable() {
        super(ProcessExecutionException.class, IOException.class);
    }

    @Override
    public byte[] call() throws ProcessExecutionException, IOException {
        //Do some work that could throw one of these exceptions
        return null;
    }

}

// This is the generic implementation. You will need to do some more work
// if you want it to support a number of exception types other than two.
public abstract class CallableWithExceptions<V, E1 extends Exception, E2 extends Exception>
        implements Callable<V> {

    private Class<E1> e1;
    private Class<E2> e2;

    public CallableWithExceptions(Class<E1> e1, Class<E2> e2) {
        this.e1 = e1;
        this.e2 = e2;
    }

    public abstract V call() throws E1, E2;

    // This method always throws, but calling code can throw the result
    // from this method to avoid compiler errors.
    public RuntimeException rethrow(ExecutionException ee) throws E1, E2 {
        Throwable t = ee.getCause();

        if (e1.isInstance(t)) {
            throw e1.cast(t);
        } else if (e2.isInstance(t)) {
            throw e2.cast(t);
        } else if (t instanceof Error ) {
            throw (Error) t;
        } else if (t instanceof RuntimeException) {
            throw (RuntimeException) t;
        } else {
            throw new RuntimeException(t);
        }
    }

}

He encontrado una manera de resolver el problema. Si se trata de ExecutionException, puede obtener uno original llamando a exception.getCause() Entonces necesita envolver su excepción en algún tipo de Excepción de tiempo de ejecución o (cuál es la mejor manera para mí) usar la anotación @SneakyThrows del proyecto lombok (https://projectlombok.org / ). Doy un pequeño ejemplo de código. Además, puede agregar algunas comprobaciones instanceof antes de lanzar una excepción para asegurarse de que este sea el que está esperando.

@SneakyThrows
public <T> T submitAndGet(Callable<T> task) {
    try {
        return executor.submit(task).get(5, TimeUnit.SECONDS);
    } catch (InterruptedException | ExecutionException | TimeoutException e) {
        throw e.getCause();
    }
}