java - tipos - Clases utilizadas para gestionar excepciones

tipos de excepciones en java

Question

¿Es bueno tener una clase con métodos cortos utilizados para detectar Excepciones?

class ContractUtils{
  public static String getCode(Contract contract) throws MyException{
    try{
      return contract.getInfo().getCode(); //throws ContractException and LogicException
    }catch(Exception e){
      throw new MyException("error during code reading:"+e.getMessage, e);
    }
  }
  //other methods like above...
}

Answer 1

Puede ser útil separar la lógica de la aplicación del manejo de errores para la legibilidad.

Pero no en la clase de utilidad porque puede olvidarse de usarla y realizar su tarea directamente y aún esperar una excepción personalizada. Colocaría esta lógica en la clase de contacto si se usa con la frecuencia suficiente (y hago que Contract.getInfo () sea privado). Otra desventaja es que puede llevar a que las clases de utilidad sean demasiado conocedoras (LoD - https://en.wikipedia.org/wiki/Law_of_Demeter ) sobre los detalles de implementación de otras clases, posiblemente rompiendo la encapsulación y haciéndolas menos sostenibles debido a una mayor dependencia .

Y, es posible que desee detectar excepciones específicas.

Answer 2

Si una excepción personalizada proporciona un contexto o valor adicional al código de llamada, entonces es útil y se recomienda su creación.

Tu enfoque para usar métodos estáticos es totalmente aceptable. Aquí hay una buena respuesta SO que define casos de uso para métodos estáticos cortos.

Answer 3

Siempre es mejor capturar y manejar excepciones por separado en su código. No se recomienda asignar una excepción personalizada común.

Consulte este enlace para conocer las mejores prácticas en la gestión de excepciones:

https://softwareengineering.stackexchange.com/questions/209693/best-practices-to-create-error-codes-pattern-for-an-enterprise-project-in-c

Answer 4

Su clase de utilidad ContractUtil introduce un nivel de indirección solo para traducir la excepción original en otra excepción:

En lugar de la llamada directa:

 return contract.getInfo().getCode()

ahora estás escribiendo el más artificial

 return ContractUtils.getCode(contract);

Pero puede haber situaciones donde esta solución se puede justificar , por ejemplo:

No tiene permitido lanzar ContractException o LogicException, y llama a este método muchas veces.

Pero si puede cambiar su firma, sería mejor rediseñar el método original para arrojar solo MyException .