A veces, hay una serie de llamadas a funciones, donde en el medio determinaste el resultado y deseas detener toda la cadena de funciones en el medio. En tal caso, ¿la siguiente forma es mala?
public ResponseObject composeResponse { try { ResponseObject response = new ResponseObject(); processA(response); processB(response); processC(response); processD(response); . . . return response; } catch (SomeFlagException e){ return response; } }donde para cada función de proceso, también es como
public void processA(ResponseObject response){ minorProcess1(response); minorProcess2(response); minorProcess3(response); . . . }En algunas condiciones particulares, digamos minorProcess3(), tienen tal caso que el resultado está determinado y el resto de los procesos no son deseados. Suponga que esto sucede en muchos de los procesos menores.
public void minorProcess3(ResponseObject response){ //some process if (someFlag){ //want end the process and return the result throw new SomeFlagException(); //SomeFlagException extends RuntimeException } }Mi mente me dice que no, porque no es una "excepción", sino un resultado esperado. Y escuché que la Excepción no marcada solo debe lanzarse cuando no se puede resolver razonablemente. Pero solo podría pensar de esta manera para hacer que el código sea limpio, de lo contrario, el código tendrá que hacer una cascada de verificación de condiciones hasta la función base.
EDITAR: Agregar información sobre mi situación. Es un proyecto web, por lo que se supone que debe devolver la respuesta adecuada con la carga útil. A veces, la solicitud debe ser respondida por un 204/40x. No se requiere carga útil y, por lo tanto, no es necesario un proceso adicional y debe abandonarse.
Sí, hacerlo es realmente una mala práctica.
Una excepción significa que algún método no pudo cumplir su contrato. El enfoque sobre el que pregunta convierte esto en lo contrario: use una excepción para significar un éxito temprano.
Aunque técnicamente funcionará, va tan en contra del significado previsto de las excepciones que tengo que recomendar enfáticamente que no se use ese enfoque.
Y escuché que la Excepción no marcada solo debe lanzarse cuando no se puede resolver razonablemente.
En mi humilde opinión, este es un mal consejo. Como el que lanza una excepción, ¿cómo puede saber si algún método de llamada en la pila de llamadas puede continuar con éxito después de su falla? Eso solo se puede decidir en el contexto de la persona que llama (ya sea que tenga una estrategia alternativa para la falla o no), y rara vez depende del tipo de excepción. No es tu responsabilidad decidir eso, e incluso si trataste de tomar esa decisión, lo más probable es que salga mal.
Por ejemplo, para la persona que llama, normalmente no importa si falló debido a NullPointerException o IOException , solo por nombrar dos ejemplos destacados de las categorías no marcadas/marcadas. Lo que importa es que fallaste, y tal vez la persona que llama sepa cómo proceder después de tu falla.
No debe lanzar una excepción como parte de la lógica de su algoritmo. Las excepciones deben indicar que algo que no queríamos salió mal
Un enfoque más limpio es hacer que los métodos process(ResponseObject) y minorProcess(ResponseObject) devuelvan un valor boolean que indique si el proceso de la respuesta debe continuar.
Ver ejemplo:
public boolean processX(ResponseObject response) { boolean shouldContinue; shouldContinue = shouldContinue && minorProcess1(response); shouldContinue = shouldContinue && minorProcess2(response); shouldContinue = shouldContinue && minorProcess3(response); . . . return shouldContinue; } Al usar el operador && , si la primera condición es falsa, la segunda no se evalúa.
Ejemplo de proceso menor:
/** * */ public boolean minorProcessX(ResponseObject response) { //some process if (someFlag) { //want end the process and return the result return false; } }