programar - ¿Es una buena práctica conocida usar un método de captura de prueba grande por método en java?

programacion en java ejemplos

Question

Recientemente me entrevistaron y el entrevistador quería que me hiciera una prueba técnica para ver mis conocimientos. Después de que lo terminé, me dio comentarios sobre cómo lo hice, lo cual no esperaba y agradecí, ya que pocos entrevistadores lo hacen si no quieren contratarte.

Una de las cosas que me dijo que vio mal de mi código fue que usé más de un bloque try-catch dentro de cada método que escribí. Esto me llama la atención ya que lo veo interesante.

Creo que en este momento debería hacer bloques try-catch donde haya un bloque de código distinguible semánticamente que tenga uno o más métodos que puedan generar las excepciones necesarias para ser capturados. La única excepción a esto que seguí fue que si dos métodos lanzan el mismo tipo de excepción, es mejor que los coloque en diferentes bloques try-catch para distinguir claramente cuándo depurar dónde y por qué se lanzó una excepción.

Esto difiere mucho de lo que el entrevistador quería que hiciera. Entonces, ¿el uso de un solo bloque try-catch por método es una buena práctica conocida? Si es una buena práctica conocida, ¿cuáles son los beneficios de hacerlo?

EDIT: Aprecio mucho sus pensamientos sobre esto, esto es muy bueno. Aunque tenga en cuenta que estoy preguntando si es una buena práctica conocida. Esto es, si la mayoría de los programadores estarían de acuerdo con esto, o esto está escrito como una buena práctica en algún libro.

Answer 1

En cuanto a mí, es más claro tener un solo bloque try-catch que incluya todo el código "peligroso" en un método. Con respecto a quién culpar cuando dos líneas lanzan la misma excepción, siempre tendrás el seguimiento de pila.

Además, tener más de un try-catch dentro de un método generalmente significa tener más de una línea de return (lo que también puede dificultar la ejecución del código a primera vista), ya que es probable que si algo sale mal en el primer try-catch , no tendrá sentido seguir ejecutando el resto del código.

Aquí puede encontrar algunas de las mejores prácticas "estándar", en caso de que las encuentre útiles.

http://howtodoinjava.com/2013/04/04/java-exception-handling-best-practices/

Answer 2

Esta es otra cosa que a menudo inicia Java-flamewar ... ;-)

Básicamente, para el desempeño solo importan las excepciones. Por lo tanto, usar algunos bloques try-catch no debería afectar en absoluto al rendimiento. En algunas opiniones, escribir código de esa manera confunde el código y ni siquiera recuerda el "código limpio", en otras, es mejor usar el try solo para las líneas que pueden generar una excepción.

Depende de usted decidir (o la convención del equipo).

Answer 3

Intento evitar la duplicación en bloques catch. Si todas las excepciones en un método reciben el mismo tratamiento en el bloque catch, entonces siga adelante y cójalos todos juntos. Si necesitas hacer cosas diferentes con ellos, cógelos por separado.

Por ejemplo, aquí podemos capturar todas las excepciones juntas, porque cualquier tipo de excepción significa que todo el método falla:

public PasswordAuthentication readAuthenticationDetails(File authenticationFile) {
try {
BufferedReader reader = new BufferedReader(new FileReader(authenticationFile));
String username = reader.readLine();
String password = reader.readLine();
return new PasswordAuthentication(username, password.toCharArray());
} catch (IOException e) {
return null;
}
}

Mientras que aquí, tenemos diferentes comportamientos de reserva para cada grupo de llamadas, por lo que detectamos por separado:

public Collection<String> readServerHostnames(File mainServerConfigFile, File backupServerConfigFile) {
String mainServerHostname;
try {
BufferedReader reader = new BufferedReader(new FileReader(mainServerConfigFile));
mainServerHostname = reader.readLine();
} catch (IOException e) {
mainServerHostname = "default-server.example.org";
}
String backupServerHostname;
try {
BufferedReader reader = new BufferedReader(new FileReader(backupServerConfigFile));
backupServerHostname = reader.readLine();
} catch (IOException e) {
backupServerHostname = "default-server.example.ru";
}
return Arrays.asList(mainServerHostname, backupServerHostname);
}

(Este código existe únicamente para ilustrar este punto sobre la captura de excepciones; le ruego que ignore el hecho de que es absolutamente horrible de otras maneras)

Answer 4

Para mí, dos bloques try-catch hacen que la mayoría de los métodos sean demasiado largos. Oculta la intención si el método está haciendo muchas cosas.

Con dos bloques try-catch, hace al menos cuatro cosas, para ser precisos

• Dos casos para flujo principal (dos bloques de prueba).
• Dos casos de manejo de errores (captura de bloques).

Preferiría hacer métodos cortos y claros con cada bloque try-catch

private getHostNameFromConfigFile(String configFile, String defaultHostName) {
try {
BufferedReader reader = new BufferedReader(new FileReader(configFile));
return reader.readLine();
} catch (IOException e) {
return defaultHostName;
}
}
public Collection<String> readServerHostnames(File mainServerConfigFile, File backupServerConfigFile) {
String mainServerHostname=getHostNameFromConfigFile(mainServerConfigFile,"default- server.example.org");
String backupServerHostName=getHostNameFromConfigFile(backupServerConfigFile,"default- server.example.ru")
return Arrays.asList(mainServerHostname,backupServerHostName );
}

Robert C. Martin en ''Clean Code'' lo lleva al siguiente nivel, sugiriendo:

si la palabra clave ''try'' existe en una función, debería ser la primera palabra en la función y no debería haber nada después de los bloques catch / finally.

Definitivamente refactorizaría el método con dos bloques try / catch separados en métodos más pequeños.

Answer 5

Para responder a su pregunta, cuando hablamos de JVM de hoy en día que en realidad están aplicando muchas optimizaciones en el código, cuando escribe un código que es ineficiente, la JVM introducirá automáticamente las optimizaciones.

Consulte la respuesta en ( Java: ¿gastos generales de introducción / uso de bloques "try-catch"? ).

Así que la buena práctica no tiene mucha importancia.

En una nota personal, creo que uno no debe encapsular nada en bloques try-catch , static , synchronized , etc., no necesariamente.

Permítanos hacer que nuestro código sea más legible para aquellos que trabajarán en esto. Si se detecta una excepción, es mejor hacerlo explícitamente que el fragmento de código lo está lanzando.

Sin adivinar para el lector, es por eso que las JVM son inteligentes, escriben como usted quiere, lo hacen mejor para los humanos y JVM se encarga de la parte de optimización.

EDITAR: He leído un montón de libros y no encontré ningún lugar que diga que un solo intento es mejor que varios pequeños.

Además, muchos en la comunidad de desarrolladores creen lo contrario.

Answer 6

También es importante considerar el contexto del código. Si está escribiendo código con IO pesado, es posible que deba saber qué partes del código están fallando. Todavía no he visto ningún punto en el que intentar ... la captura esté destinada a darle la oportunidad de recuperarse de un problema.

Por lo tanto, si obtiene una excepción de IO en la lectura de un archivo, es posible que desee volver a intentar la lectura. Lo mismo con la escritura. Pero si tuvieras un gran intento ... atrapar, no sabrías cuál volver a intentarlo.

Answer 7

Yo diría que si te encuentras envolviendo dos bloques de código separados con try/catch , deberías considerar refactorizar esos bloques en métodos separados. Si este es un patrón que usó en su entrevista, tal vez malentendió a su entrevistador.

Es perfectamente correcto usar dos bloques try/catch si el algoritmo lo requiere. A menudo he usado un nuevo try/catch en un bloque catch para garantizar una limpieza segura por lo que no es posible una declaración general.