que - programacion java 2017 pdf

¿Es buena programación tener un tipo de excepción de retorno?

Question

Me encontré con una situación extraña durante un caso de uso en un proyecto: ESQL está llamando a un método java, enviándole un parámetro de entrada String que el método desempañará, aplicará cierta lógica y luego almacenará información útil del objeto desorganizado. Por lo tanto, el método debe arrojar una JAXBException o utilizar un try catch para manejar las posibles excepciones.

El problema con esto es que ESQL no puede invocar un método java que incluye un lanzamiento en la firma. PERO, queremos que los errores vuelvan al nodo de acceso MBNode anteriormente, por lo que se puede manejar de forma adecuada allí, por lo tanto, la captura de prueba está fuera de la imagen.

Me llamó la atención que bueno, ¿no es posible devolver un tipo de Excepción cuando nos encontramos con un problema, y ​​nulo si no? Así que escribí un método simple para hacerlo, y aunque no recibí advertencias o errores, me pareció que estaba mal en el sentido de una buena programación.

Por ejemplo:

public Exception doStuffAndCheckForErorrs(String inString)
{
    if(inString.equals(null))
    {
       return new Exception("Your string is null");
    }
    else
    return null;
}

Pero tengo un terrible presentimiento de hacer algo de esta manera.

Estoy abierto a cualquier pensamiento o soluciones diferentes a esto, especialmente si hay una forma de evitar el problema de la firma de ESQL.

ACTUALIZAR :

Agregar referencia de por qué el procedimiento ESQL no puede llamar a un método java con una cláusula throws en la firma.

Extracto de Este enlace en la sección de la declaración CREATE PROCEDURE:

"Cualquier método Java que desee invocar debe tener la siguiente firma básica: public static (<0 - N parameters>) donde debe estar en la lista de tipos de datos Java IN en la tabla en la asignación de tipos de datos ESQL to Java (excluyendo el REFERENCE type, que no está permitido como valor de retorno) o el tipo de datos vacío de Java. Los tipos de datos de parámetros también deben estar en la tabla de asignación de tipos de datos ESQL to Java. Además, el método Java no puede tener una excepción arroja una cláusula en su firma ".

Answer 1

Returning Exception es "rápido y sucio". Puede ser muy poderoso y útil, pero esto debe evitarse si es posible.

La invocación en ESQL se realiza así por una buena razón que no explicaré aquí, pero puede eludirla utilizando RuntimeException que no aparece en la definición del método.

Answer 2

Un caso de uso que especifica lanzar una excepción suena como si estuviera mal escrito. ¿Cuál es el motivo comercial o arquitectónico para lanzar una excepción?

Una alternativa sería lanzar una RuntimeException o una subclase personalizada. Eso le permitiría dejarlo fuera de la firma del método.

De nuevo, el caso de uso parece extraño.

Answer 3

Esto no es realmente una pregunta sobre Java, es una pregunta sobre ESQL.

ESQL es capaz de hacer frente a las excepciones de Java lanzadas a través del código JNI en ESQL, usted debería obtener un error BIP2917.

Inicialmente pensé que esto podría haber sido un problema con el método de resolución ESQL, pero en IIB v9 pude llamar con éxito el siguiente método:

public static void sayHello() throws Exception{
  System.out.println("hello");
}

Esto me hace pensar que quizás haya algo más que esté mal con la definición de función / procedimiento externo de ESQL.

Answer 4

La respuesta directa a su pregunta es:

No, no es una buena programación tener un tipo de excepción de retorno. El mecanismo debe suceder cuando algo va mal, por lo tanto, un tipo de Excepción de retorno significa que desea recibir la consecuencia de algo que salió mal.

Entiendo que no puedes lanzar Exception, por lo que debes manejar el caso con otro enfoque.

El enfoque booleano está bien cuando quieres verificar algo de trabajo: bueno = devuelve verdadero, malo = devuelve falso.

La encapsulación de valores en un Objeto se entiende cuando desea obtener los resultados del trabajo: bueno = devolver el nuevo YourResultObject (val1, val2, ..., valx), bad = return null.

Answer 5

Lo que puede hacer es usar códigos de retorno como los programas C utilizados para informar sus estados.

Alternativamente, también puede crear un Enum y devolver el Enum; ambos son más flexibles que el enfoque booleano si desea diferenciar entre los diferentes tipos de errores.

    public Enum ReturnCodes {
         SUCCESS,
         NULLSTRING,
         ...,
         OTHERERROR,
    }

Answer 6

El punto aquí es que no se puede DECLARAR que se lanzará una excepción; aún puede lanzar una RuntimeException, sin agregar una cláusula throws.

Entonces, si ajusta su JAXBException en una RuntimeException, puede lanzarla y manejarla según sus requisitos, sin romper ninguno de los requisitos. No estoy seguro de si haría eso; No me gustaría devolver un tipo de excepción, ya que no está destinado a ser usado como código de retorno.

Asegúrese de que esta forma sencilla de manejar el problema no rompa la biblioteca ESQL, ya que estará omitiendo parte de su código, posiblemente dejando parte de él colgando.