Cómo evitar la duplicación de complicados bloques catch

Question

tengo este código:

try { 
    do_stuff(); 
    return do_more_stuff(); 
} catch (UnsupportedEncodingException e) { 
    throw CustomException.programmer_error(e); 
} catch (ProtocolException e) { 
    throw CustomException.programmer_error(e); 
} catch (MalformedURLException e) { 
    throw CustomException.programmer_error(e); 
} catch (SocketTimeoutException e) { 
    throw new CustomException(e); 
} catch (IOException e) { 
    throw CustomException.unexpected_error(e); 
} 

ahora necesita tener todos esos bloques de captura en otra función similar. ¿Cuál es la mejor manera de evitar la duplicación aquí?

Tenga en cuenta que el código dentro de los dos bloques de prueba no es muy similar.

También realmente no puedo poner el conjunto de las capturas más arriba.

Nota, yo preferiría evitar:

try { 
    do_stuff(); 
    return do_more_stuff(); 
} catch (Exception e) { 
    handle_exception_via_rtti(e); 
} 

Answer 1

personal que iba a tratar de hacer la parte

do_stuff(); 
return do_more_stuff(); 

se ajustan a un formato más general con el fin de aplicar la estrategia (como un patrón).

Luego puede refactorizar todos los lugares donde llama a este tipo de bloque para que puedan llamar a un bloque más generalizado (donde las capturas se distribuyen solo una vez).

Answer 2

Nota, preferiría evitar:

Entonces, o simplemente vivir con ella, o esperar hasta JDK7 viene con Multicatch para que pueda reescribir como:

try { 
    do_stuff(); 
    return do_more_stuff(); 
} catch (UnsupportedEncodingException | ProtocolException | MalformedURLException e) { 
    throw CustomException.programmer_error(e); 
} catch (SocketTimeoutException e) { 
    throw new CustomException(e); 
} catch (IOException e) { 
    throw CustomException.unexpected_error(e); 
} 

Alternativamente, también puede mover esto al constructor de CustomException y realizar una captura global (desagradable), pero luego deberá agregar un grupo de (desagradables) if/else bloques para determinar el tipo de causa de la excepción. Con todo, preferiría seguir el camino como ya lo hiciste.

actualización: otra alternativa es dividir/refactorizar las líneas de lo que potencialmente puede lanzar la excepción como tareas separadas en otros bloques del método de lanzamiento CustomException. P.ej.

try { 
    do_stuff_with_encoding(); 
    do_stuff_with_url(); 
    do_stuff_with_ws(); 
    // ... 
    return do_more_stuff(); 
} catch (SocketTimeoutException e) { 
    throw new CustomException(e); 
} catch (IOException e) { 
    throw CustomException.unexpected_error(e); 
} 

... 

public SomeObject do_stuff_with_encoding() throws CustomException { 
    try { 
     do_stuff(); 
    } catch (UnsupportedEncodingException e) { 
     throw CustomException.programmer_error(e); 
    } 
} 

public SomeObject do_stuff_with_url() throws CustomException { 
    try { 
     do_stuff(); 
    } catch (MalformedURLException e) { 
     throw CustomException.programmer_error(e); 
    } 
} 

public SomeObject do_stuff_with_ws() throws CustomException { 
    try { 
     do_stuff(); 
    } catch (ProtocolException e) { 
     throw CustomException.programmer_error(e); 
    } 
} 

Answer 3

Depende de por qué el do_stuff y do_more_stuff arrojan las excepciones marcadas. ¿Están haciendo eso para obligar al usuario a tratar la excepción? Si es así, entonces intenta evitar:

try { 
    do_stuff(); 
    return do_more_stuff(); 
} catch (Exception e) { 
    handle_exception_via_rtti(e); 
} 

es una buena cosa.

Si su código sólo atrapa Exception y el do_stuff y do_more_stuff más adelante agregar excepciones adicionales, es probable que nunca se sabe sobre el cambio y el hecho de que el código de ahora podría estar equivocado.

Por lo que es posible que tenga que tratar con throwing the kitchen sink y trate todas esas excepciones, a menos que los métodos puedan cambiar a excepciones no verificadas.

Por otro lado, si los métodos arrojan excepciones comprobadas solo porque el programador era flojo al tratar con ellos y solo quería pasar el dinero, tal vez está mirando esto desde el ángulo equivocado.

Answer 4

¿Qué hay de introducir una clase de acción genérico que puede tener subclases:

public class Action { 
    public void runWithHandlers() throws Exception { 
     try { 
      run(); 
     } catch (UnsupportedEncodingException e) { 
      throw CustomException.programmer_error(e); 
     } catch (ProtocolException e) { 
      throw CustomException.programmer_error(e); 
     } catch (MalformedURLException e) { 
      throw CustomException.programmer_error(e); 
     } catch (SocketTimeoutException e) { 
      throw new CustomException(e); 
     } catch (IOException e) { 
      throw CustomException.unexpected_error(e); 
     } 
    } 
    public void run() throws Exception { 
     // TODO subclasses of Action must implement this 
    } 
} 

A continuación, en otra parte de su código se instancia una de las subclases de Acción y llaman runWithHandlers():

new MyAction().runWithHandlers(); 

Answer 5

Si puede pagar Scala, compruébelo: puede hacer coincidir el patrón con la excepción en el bloque catch. Ver Scala for Java Refugees Part 4: Pattern Matching and Exceptions.