Política de manejo de excepciones en bibliotecas

Question

Al compilar una biblioteca .NET, ¿cuál es su política de manejo de excepciones? En específico, ¿cuál es su política sobre el manejo de excepciones dentro de las llamadas a bibliotecas y exponerlas al código de llamadas?

Por ejemplo,

• tratarían a una función de biblioteca como cualquier otro, permitiendo así que todas las excepciones que no puede manejar el flujo de ella tal cual?
• ¿Podría crear una excepción personalizada para esa biblioteca?
• ¿Capturaría todas las excepciones y arrojaría en su lugar la excepción de la biblioteca? ¿Establecerías la excepción original como la excepción interna de la excepción de la biblioteca?
• ¿Cómo afectaría la dependencia de la biblioteca a un DB su política de manejo de excepciones?

¿Qué pautas y reglas sugeriría para el manejo de excepciones en una biblioteca .NET?

Answer 1

tratarían a una función de biblioteca como cualquier otro, permitiendo así que todos los excepciones que no puede manejar el flujo de que tal como están?

Sí, esta es definitivamente la estrategia predeterminada.

¿Podría crear una excepción personalizada para esa biblioteca?

Sí, si las personas que llaman pueden hacer posiblemente algo acerca de la situación y para hacerlo tienen que ser capaces de distinguir la excepción de otras excepciones. Pero eso es bastante raro.

¿Cómo afectaría la dependencia de la biblioteca a un DB su política de manejo de excepciones?

Una dependencia base de datos podría implicar la exposición de los ajustes que permiten a las personas que llaman especifican la forma en la biblioteca maneja ciertas excepciones (por ejemplo, MaximumDeadlockRetries).

¿Capturaría todas las excepciones y arrojaría la excepción de la biblioteca en su lugar? ¿Establecería la excepción original como la excepción interna de la biblioteca ?

No, no todas las excepciones. Para excepciones específicas, es remotamente posible, aunque el único caso en el que puedo pensar dónde podría querer hacer esto es cuando mi biblioteca ya ha intentado manejar la excepción (como en el escenario de la base de datos anterior) y ha fallado.

Answer 2

• Dejo todas las excepciones burbujear que creo que el usuario puede manejar. Esto es básicamente cosas que creo que debería esperar ver (IO, etc.)
• Envuelvo todas las ecepciones que quiero volver a generar de una manera más abstracta. En un asignador O/R, tenía una "DataAccessException" que obtenía cualquier Excepción de SQL internamente, por lo que el usuario no tiene que lidiar con sus intrínsecos. La idea aquí es que cualquier aplicación quiera saber si se produjo una excepción de nivel de SQL, pero ni siquiera puede intentar arreglarla de todos modos (gracias a que la base de datos es de muchos tipos, etc.), por lo que un contenedor es bueno.
• Nunca utilizo un genérico atrape todas las cosas fuera de la depuración.
• Siempre tengo un controlador de nivel superior (nivel de dominio de aplicación - evento de excepción no controlada) para tratar de mostrar al usuario una excepción inesperada y enviarla a soporte.

Excepciones personalizadas, cuando tienen sentido. Este no es el caso muy a menudo gracias a algunas excepciones genéricas en el marco.

Answer 3

Una biblioteca que engloba varias clases diferentes que pueden arrojar excepciones diferentes, en mi humilde opinión no debe permitir que las excepciones desde dentro se filtren como sus tipos originales. En su lugar, deben estar envueltos en una excepción específica de la biblioteca que se relacione tan claramente como sea posible con el tipo original de la excepción.

Por ejemplo, MagicDatabaseLibrary podría definir MagicDatabaseException, que a su vez tiene unas pocas excepciones MagicDatabaseTimeoutException derivada, MagicDatabaseAuthenticationException, etc. Si una base de datos SQL Server lanza una excepción de tiempo de espera de SQL Server (como se llame), que debe ser envuelto en una MagicDatabaseTimeoutException . Del mismo modo para cualquier otra excepción semi-esperada que pueda ocurrir.

Si esto no se hace, el código que llama a la biblioteca no tendrá más opción que usar "manejo de excepciones de Pokemon" si tiene alguna esperanza de resolver problemas potenciales en la base de datos. Por ejemplo, si se supone que el código de llamada maneja la situación en la que un usuario proporciona credenciales para iniciar sesión en una base de datos y la conexión falla, debe ser capaz de detectar esa excepción. Si el código de llamada no sabe qué tipo de excepción será, no hay mucho que pueda hacer, excepto capturar todas las excepciones, esperar que sea el resultado de una credencial incorrecta o algo así, y presentar un mensaje al usuario diciendo que la conexión falló . No es tan útil como proporcionar una excepción envuelta.