opinion: uso de checked exceptions en logica/api

[jvagliat]

Me gustaria obtener opiniones sobre el uso, abuso o mal uso de excepciones en el diseño de la logica de mi aplicacion o de una api en general. Consideren la siguiente interfaz:

Código:

public interface OrderService{
   //...
   public void changeOrderPriority(String orderId, int priority) 
                        throws NonexistentOrderException, IllegalPriorityException;
   //...d
}

Yo he estado haciendo interfaces de este tipo, que lanzan checked exceptions ante errores que no son "fatales"... no se como decirlos... como la perdida de una conexion a una base de datos.

Hace unos dias me hicieron un comentario que me a dejado pensando:

Una recomendación es no usar nunca excepciones para controlar el flujo de tu programa, como estas haciendo en tu ejemplo para señalar que un parametro no esta o que un query no devolvio nada. Las excepciones son normalmente para errores graves no previstos para no confudir las cuestiones "leves", que un query no devuelva nada puede ser bien normal, de las "graves", como que la BDD no está accesible o que el SQL dio un error.

Como dije, me a dejado pensando, me gustaria escuchar su opinion acerca de si estoy haciendo un mal uso del concepto de excepciones.

[chuidiang]

Hola:

Mi opinión. Depende de varias cosas.

En general, si el método no sabe qué hacer con el error se debe lanzar una excepción. Si sí sabe que hacer o puede más o menos "arreglarla", no se debe lanzar, pero hay que matizarlo un poco.

Depende del código que estás haciendo. Si estás haciendo una apliación completa es distinto de si estas haciendo una especie de librería.

Por ejemplo, si haces una librería de conexiones a base de datos, debes lanzar como excepciones todos los problemas que tengas. Una librería no debería escribir en pantalla ni sacar ventanas de error, ya que el estilo con el que lo hagas puede no tener nada que ver con el estilo del que haga la aplicación que use tu librería. La aplicación debería enterarse de todos los posibles problemas en la llamda a métodos de la librería y decidir si los muestra o no al usuario y cómo lo hace.

Si estás haciendo una aplicación y el método no es un método reutilizable en muchos sitios, entonces no tiene sentido lanzar la excepción, ya que el que la reciba va a hacer algo que posiblemente puedas hacer en el método.

Si te fijas, la api de java no saca ninguna salida de error por ningún sitio, simplemente lanza excepciones en los errores y da la posibilidad a la aplicación de capturarlas y tratarlas.

Se bueno.

[GreenEyed]

Exacto. Lo que quería decir yo es lo que comenta chuidiang. La idea es que cuando lanzas una excepcion, la idea es que no puedes seguir con lo que estas haciendo y tienes que hacer una "salida de emergencia" y hacerle notar al metodo que te llamo que ocurrió algo imprevisto. Lo que ocurre es que es cuestion de contexto. Por ejemplo, si un usuario te puede introducir un texto libre en un campo, pero en la base de datos no caben mas de 100, es normal que te puedan intentar introducir un texto mayor que 100, y lo que tendras que hacer es tratar ese "error" pero es algo "esperado", asi que muestras un mensaje, lo que sea y ya esta. En cambio, si al intentar ejecutar esa misma instruccion te da un error SQL, aunque sea por que un campo es mas largo, entonces eso sí es un problema, por que teoricamente no tendría que pasar: es una excepción.

No es un concepto 100% seguro y no es blanco/negro, pero la idea es mirar quien puede hacer algo con ese error y si es algo esperado o no. Si es algo inesperado que no deberia ocurrir o no podemos hacer nada con ese error, entonces es una excepcion. Si es algo esperado por que puede pasar y/o nosotros mismos vamos a tratar el error, entonces no se lanza excepcion.

Lo que nunca es recomendable hacer, es usar las excepcion para controlar "el flujo de operaciones normal", ya que hay programadores que por pereza de poner un if/else o escribir correctamente la condicion de finalizacion de un bucle, hacen un try/catch y provocan una excepcion para "saltarse" un trozo de codigo o acabar un bucle. Y eso si que no es correcto, lo mires por donde lo mires.

Hay que tener en cuenta que lanzar una excepcion es una operacion, computacionalmente, bastante costosa en tiempo/recursos, asi que en funcionamiento "normal" no deberia lanzarse "ninguna".

Espero que quede más claro ahora. .
<S>

PD: Como dice chuidiang, no es lo mismo un API que una aplicación. Una API normalmente no puede tratar el error, asi que suele lanzar excepciones. El ejemplo que pones tu es una API.

[TolaWare]

En la teoria, las excepciones fueron creadas para manejar todo tipo de errore, desde los graves hasta los recuperables. Pero manejar todos los errores o excepciones con Exceptions, es bastante costoso computacionalmente hablando, ya que crear clases lanzarlas, etc, es costoso. Ademas genera mucha basura que luego el garbage collector debe eliminar.

Basicamente, como dijieron arriba, el uso de Exceptions dbe estar limitado, al rendimiento del sistema y a si es una API o no.

[jvagliat]

Como ven suelo dejar cosas colgadas... Espero que se prendan de nuevo a pesar del tiempo(tal vez se hallan olvidado del tema)...

A ver, entiendo lo que dicen, pero de todos modos estoy muy "viciado" en mis desarrollos y me cuesta ver con claridad cuan bien estoy haciendo las cosas. El asunto es que no me termina de gustar el uso que le estoy dando a las excepciones.

chuidiang dijo:

Si estás haciendo una aplicación y el método no es un método reutilizable en muchos sitios, entonces no tiene sentido lanzar la excepción, ya que el que la reciba va a hacer algo que posiblemente puedas hacer en el método.

Lo que estoy haciendo es una aplicacion. Uso struts, me intereza el mvc y la separación de concerns del mismo (tengo la duda que ya va a llegar de donde entra la persistencia en el mvc... otro tema) ya que la idea es:

• poder cambiar facilmente la presentacion
• reutilizar luego la logica en una aplicación standalone
• modificabilidad en general (se supone que va a tener una larga vida el sitio y el sistema)
• etc. bla bla bla

Ahora, en el caso del ejemplo. Si quieren hacer algo (cambiar una prioridad) y no se existe el objetivo del cambio (el pedido que me pasan) largo una excepcion no me acuerdo el nombre pero especifica para ese caso. Algo similar con la otro execpcion. Mi idea es como dije tener la logica bien cohesiva y reutilizable. En estos casos no se que hacer y quiero que la interfaz informe de ese error en particular. Vamos al ejemplo. El usuario pide cambiar la prioridad del pedido X por P. La logica encuentra que no existe el pedido X entonces largo la excepcion especifica UnexistentOrderException ya que no puedo realizar el cambio. De esta forma la accion (el controlador en cualquier caso) sabe que tiene que decir "Pedido inexistente"...

Como punto a favor veo que el que use estas interfaces, esta logica, para hacer otra interfaz (por ejemplo la standalone) va a saber con solo ver la signatura que cosas pueden pasar y actuar en funcion de ello.

Lo que noto es que tengo muuuuchos tipos de excepciones. Lo hago asi para que sepan basicamente con exactitud que paso.

Que opinan esta mal el uso que estoy haciendo de ellas? Como lo harian?