¿Los controladores de eventos en C# deberían generar alguna excepción?

Question

Como regla general, ¿hay alguna circunstancia en la que sea aceptable que un método responsable de escuchar un evento genere una excepción (o permita que lancen) que la clase que plantea el evento deba manejar?

Dado que tal excepción impediría que otros oyentes de ese evento sean llamados posteriormente, parece un poco "antisocial" permitir que esto suceda, pero por otro lado, si hay una excepción, ¿qué debería hacer? ?

Answer 1

Lanzar una excepción desde un controlador de eventos es en muchos aspectos similar a lanzar una excepción desde un método IDisposable.Dispose (o un destructor C++). Hacerlo crea estragos en la persona que llama porque los deja con poca opción.

1. Ignore la excepción y deje que se propague. Esto rompe su contrato para informar a todos los oyentes de un evento. Este es un problema muy real si alguien encima de ellos en la pila detecta la excepción.
2. Captúralo y llama a los otros controladores y vuelve a lanzar. ¿Pero qué sucede si uno de los otros tira también?
3. Trague la excepción. Esto es simplemente malo en general. Las fuentes de eventos no deberían tener conocimiento de quién llama y, por lo tanto, no pueden saber qué están tragando.
4. Bloquea el proceso porque estás en un brindis.

De todos estos # 4 es la mejor opción. Pero esto es rara vez hecho y no se puede contar con.

creo que en su componente que realmente sólo tiene unas pocas opciones

• a la que llama el código que está lanzando y están en la mejor posición para manejar la excepción. Si no es manejable por usted, entonces no es razonable esperar que sea manejado por otra persona. Por lo tanto, rompa el proceso y termine con esto.
• no llame a la API que arroja

Answer 2

En un mundo ideal, los controladores de eventos no deberían generar excepciones. La generación de una excepción en un controlador de eventos tiende a generar situaciones muy difíciles de manejar y comportamientos inesperados. Como mencionaste, esto bloquea a los controladores de eventos posteriores para que no vean el evento, y la excepción se propaga al código del productor del evento, ya que generó el evento.

Idealmente, los controladores de eventos deben ser rápidos (si son de larga duración, deben intentar programar el trabajo en una secuencia separada) y lo más cerca posible de errores.

Answer 3

En una palabra ideales, no debería existir excepciones. En una palabra real del desarrollador, las excepciones siempre se esperan y deben ser interceptadas (atrapadas), propagadas o inhibidas según la situación lo requiera.

Así

son alguna vez cualquier circunstancia en la que que es aceptable para un método responsable de escuchar a un evento a lanzar una excepción

Sí. Puede esperar una excepción de cada método, responsable o no de un evento.

Para la captura de casi todos los excepción de un uso de aplicaciones de Windows:
AppDomain.CurrentDomain.UnhandledException
Application.ThreadException

Answer 4

Los únicos dos tipos de excepciones que procedan de eventos son los graves, potencialmente proceso termina como System.OutOfMemoryException o System.DllNotFoundException, y cosas que son claramente errores de programación, como System.StackOverflowException o System.InvalidCastException. Atrapar y eliminar este tipo de excepciones nunca es una buena idea: déjelos flotar hasta la cima y deje que el desarrollador decida qué hacer con ellos en un nivel de aplicación.

En cuanto al resto ... cualquier excepción común o jardín de excepción como System.IO.IOException se debe manejar dentro de su evento, y debe tener algún mecanismo para devolver esas condiciones de error a la persona que llama.

Answer 5

Algunas de las respuestas aquí sugieren que es malo tirar desde un controlador de eventos ("crea estragos para quien llama", "tiende a provocar situaciones muy difíciles de manejar y comportamientos inesperados", ...).

En mi humilde opinión esto no tiene sentido.

En el caso general, está perfectamente bien lanzar desde un controlador de eventos. No se ejecutarán otros manejadores de eventos, por supuesto, ni el controlador de eventos que arroja la ejecución hasta el final, ni ningún otro código entre el disparo del evento y el punto donde se detecta. ¿Y qué? Es perfectamente normal que el código no se ejecute cuando se lanza una excepción: si necesita garantizar que se ejecuta, entonces use un bloque finally.

Por supuesto, en cualquier caso específico es posible que desee considerar las excepciones, si las hay, que es apropiado manejar, al igual que con cualquier otro código.

Como siempre, no existen reglas estrictas que se apliquen en todas las circunstancias. Una de las respuestas aquí dice "los controladores de eventos deben ser rápidos ... y cerca de la ausencia de errores ...". Un contraejemplo es el evento ASP.NET Page.Load.

Una regla general en .NET es que casi siempre es una mala idea tragarse todas las excepciones: esto se aplica a los manejadores de eventos al igual que a cualquier otro código.

Así que la respuesta a la pregunta original "hay nunca ninguna circunstancia en la que es aceptable para un método responsable de escuchar a un evento para lanzar una excepción" es muy definitivamente sí.

Al igual que la respuesta a la pregunta "¿hay alguna circunstancia en la que sea aceptable que un método responsable de escuchar un evento trague excepciones" también es afirmativa.