Excepciones y abstracciones

Question

¿Cuándo deberías lanzar una excepción personalizada?

p.ej.Tengo un código que se conecta a un servidor.El código que se conecta al servidor genera una IOException cuando no se puede conectar.En el contexto del método al que se llama, esto está bien.También está bien en el código de red.

Pero como esto representa no tener conexión (y por lo tanto no funcionar), la excepción llega hasta la interfaz de usuario.En esta etapa, una IOException es muy ambigua.Algo como NoConnectionException sería mejor.

Entonces, mi pregunta es:¿En qué etapa debería detectar una excepción para lanzar otra excepción (personalizada) que se ajuste mejor a la abstracción?

Answer 1

Yo esperaría excepciones para hablar en términos de lo que he pedido el método origina que hacer. por ejemplo.

read -> ReadException
connect -> ConnectException
buildPortfolio -> FailedToBuildPortfolioException

etc. Este abstrae lo que está pasando debajo de las mantas (es decir, que se conectan a través de enchufes, etc.). Como regla general, cuando se crea una interfaz para un componente, a menudo se crea una excepción correspondiente o un conjunto de excepciones. Mi interfaz se llama Component, y mis excepciones son por lo general ComponentException (por ejemplo RateSource y RateSourceException). Es consistente y fácil de exportar a diferentes proyectos como un conjunto de componentes completa.

El inconveniente es que crear un buen montón de excepciones, y puede que tenga que realizar un buen montón de traducciones. La ventaja es que (como se haya identificado) se obtiene poca o ninguna fuga de abstracción.

En algún momento durante la jerarquía de llamadas de método (y por tanto excepciones) puede decidir que no hay recuperación puede tener lugar (o sea en un lugar inadecuado) y traducir a excepciones sin marcar, para ser manejados más tarde.

Answer 2

Sé que esto es etiquetado como "independiente del idioma", pero no creo que realmente es. Viniendo desde la perspectiva de un C ++, espero que muy pocas operaciones básicas para lanzar una excepción - la Biblioteca C ++ estándar sólo utiliza excepciones en muy pocos lugares. Así que mi propio código es a menudo el primer lugar en el que se pueden generar excepciones. En ese código, me gusta una jerarquía muy plana - No quiero ser jugar con cientos de capturas () cláusulas más adelante en el código, y nunca he entendido Java y aparente obsesión C # 's con la creación de jerarquías barrocas de clase y espacio de nombres <. / p>

Por lo tanto, para mi código C ++ - un tipo de excepción, que contiene un mensaje de error significativo, por biblioteca. Y otro para el ejecutable final.

Answer 3

Creo que hay dos cuestiones ocultas aquí: a) ¿Cuándo se debe ocultar una excepción detrás de una excepción diferente. b) ¿Cuándo se debe utilizar una excepción personalizada para esto.

a) diría: cuando cada vez una excepción viaja a través de la frontera de dos capas en la aplicación, se debe conseguir escondido detrás de una excepción que es más adecuada exploración para la nueva capa. Ejemplo:. Porque están haciendo algunas cosas a distancia, se obtiene una ConnectionWhatEverException

Sin embargo, la persona que llama no debe estar al tanto de los problemas de conexión. Dado que sólo quiere conseguir un cierto servicio realizado, por lo que consigue un ServiceOutOfOrderException. La razón de esto es: Dentro de la capa, haciendo la comunicación remota, es posible hacer algo útil con un ConnectionException (reintentar, escribir en una cola de restitución ..). Una vez que dejó esa capa, nadie sabe cómo manejar un ConnectionException. Pero deben ser capaces de decidir, ¿qué hacen, cuando el servicio no funciona.

b) Cuando no hay coincidencia de Excepción existente. Hay un par de excepciones útil en Java, por ejemplo. Yo uso IllegalState y IllegalArgument con bastante frecuencia. Un fuerte argumento a favor de una nueva clase de excepción es, si tiene algún contexto útil proporcionar. Por ejemplo el nombre del servicio que no podría ser un argumento de un ServiceFailedException. Eso sí, no crear una clase para cada llamada a un método, o algo por el estilo. 100 clases de excepciones no son un problema, siempre y cuando que tienen un comportamiento diferente (es decir al menos diferentes campos). Si sólo se diferencian por su nombre y residen en el mismo nivel de abstracción, que sean una excepción, y poner los nombres diferentes en el mensaje o un campo único de esa clase de excepción.

c) Al menos en java existe la discusión acerca de excepciones controladas. Envuelvo los directamente en un uno sin control, porque no me gusta la clase seleccionada. Pero eso es más una opinión continuación consejo.

Answer 4

¿Hay algún caso en el que se obtendría NoConnectionException que no está causado por un problema IO? Por el contrario, es saber si la causa se basa IO o no va a ayudar al cliente a recuperarse con sensatez?

Answer 5

¿Cuándo deberías lanzar una excepción personalizada?

I.Cuándo puede proporcionar más información (de diagnóstico).

Nota:Es posible que esta información adicional no esté disponible en el lugar donde se produjo la excepción original (IOException).Las capas progresivas de abstracciones pueden tener más información para agregar, como ¿qué estaba tratando de hacer que condujo a esta excepción?

II.Cuándo no debe exponer los detalles de implementación:es decir.quieres que la (¿ilusión de?) abstracción continúe.

Esto puede ser importante cuando el mecanismo de implementación subyacente puede cambiar.Envolver la excepción subyacente en una excepción personalizada es una buena forma de aislar a sus clientes de los detalles de implementación (al elevar el nivel de abstracción).

III.Tanto yo como II

NOTA:Además, sus clientes deberían poder sintonizar el nivel exacto de información que les interesa o, más bien, deberían poder ignorar cualquier cosa que no les interese.Por lo tanto, es una buena idea derivar las excepciones personalizadas de IOException.