Cuándo usar excepciones personalizadas contra excepciones existentes frente a excepciones genéricas

Question

Estoy tratando de averiguar cuál sería la forma correcta de excepciones para lanzar para una biblioteca que estoy escribiendo. Un ejemplo de lo que necesito manejar es registrar a un usuario en una estación. Lo hacen escaneando una insignia. cosas posibles que podrían salir mal incluyen:

• Su insignia está desactivado
• Ellos no tienen permiso para trabajar en esta estación
• La insignia de escaneado no existe en el sistema
• que ya están conectado a otra estación a otra parte
• la base de datos se ha reducido
error
• interno DB (que sucede a veces si la placa no consiguió configurado correctamente)

Una aplicación que use esta biblioteca tendrá que manejar estas excepciones de una forma u otra. Es posible que decidan simplemente decir "Error" o que quieran darle al usuario más información útil. ¿Cuál es la mejor práctica en esta situación? Crear una excepción personalizada para cada posibilidad? Use las excepciones existentes? Use Exception y pase el motivo (throw new Exception("Badge is deactivated.");)? Estoy pensando que es una especie de combinación de los dos primeros, utilizando las excepciones existentes cuando corresponda y creando nuevas cuando sea necesario (y agrupando excepciones donde tenga sentido). pasar

Answer 1

Tiene dos especies de excepciones.

Aquellas que son específicas para su aplicación, donde es bueno evitar las excepciones existentes.

Las excepciones específicas de la aplicación deberían simplificar los casos de uso para las personas que usan sus bibliotecas. 3 de sus excepciones específicas de la aplicación son cosas que los usuarios pueden hacer. El cuarto (el distintivo no existe) claramente no es de procedimiento, pero es mucho más serio.

Parece que tiene dos errores específicos de la aplicación: cosas orientadas al usuario y errores administrativos.

Las otras son parte de otra tecnología; es decir, errores en la base de datos. Usted puede, generalmente, ignorar estos. Si la base de datos no está disponible, la API generará errores y podrá hacer que aparezcan burbujas en su biblioteca.

También puede "ajustar" estos como una excepción específica de la aplicación que contiene una excepción de nivel inferior. Esto a veces es útil si hay mucha tecnología de nivel inferior. En tu caso, es solo una base de datos. Ignore y deje que los errores de DB pasen.

Answer 2

excepción de uso y en la razón (arrojar nueva Excepción ("Insignia está desactivado.");)

Esto sin duda es una mala práctica, porque no cumple con el propósito de excepciones - no sólo para señalar una situación anormal, pero proporcionar la capacidad de distinguir excepciones en un nivel de tipo, por lo que el usuario de un módulo puede tomar una decisión dependiendo de un tipo de excepción.

En general, es bueno reutilizar las excepciones estándar en la medida en que puedan describir completamente las situaciones anormales que su código realmente enfrenta. Es bastante difícil dar un consejo en una situación actual, porque las excepciones a menudo pueden depender de la semántica (excepción de argumento u operación inválida excepción (tal vez adecuado para el caso 'Su insignia está desactivada', por ejemplo).

Answer 3

Estoy esencialmente de acuerdo con su pensamiento actual

• Use excepciones centrales existentes en su caso:.. ArgumentException, InvalidOperationException, etc. no trate de cambiar la finalidad de excepciones que son específicas de algún otro módulo Use las excepciones que tienen un propósito claro, genérico, y no los use para las reglas comerciales. Por ejemplo, InvalidOperationException debe indicar una mala operación con respecto a su API, no una violación de una regla comercial.
• Para excepciones específicas de su biblioteca, cree una clase de excepción base, BadgeAuthException, y siempre arroje eso. Los escenarios específicos cada uno debe tener su propia subclase (BadgeDeactivatedException, NoPermissionsAtWorkstationException, etc.) De esta forma, las aplicaciones pueden manejar los subcasos individuales por separado si así lo desean, pero también pueden atrapar el genérico BadgeAuthException si no quieren arrastrarse en detalles
• Hagas lo que hagas, asegúrate de que el campo Message siempre contenga información útil más allá del nombre de la excepción.

Answer 4

Creo que debe tener una excepción de base y una excepción de subtipo para cada una de las situaciones que describe (en realidad puede hacer que db down y error interno de db tengan la misma excepción base). El punto clave es que es una buena práctica tener sus propias excepciones para su biblioteca.

Answer 5

Casi nunca se puede equivocar al tener clases de excepción detalladas que extienden una clase base común. De esta forma, las personas que llaman que necesitan atrapar específicamente a algunos y dejar que otros lo hagan pueden hacerlo, y las personas que llamen y quieran tratarlos a todos juntos pueden hacerlo.