¿Puedo tener una fuerte excepción de seguridad y eventos?

Question

Supongamos que tengo un método que cambia el estado de un objeto, y dispara un evento para notificar a los oyentes de este cambio de estado:

public class Example 
{ 
    public int Counter { get; private set; } 

    public void IncreaseCounter() 
    { 
     this.Counter = this.Counter + 1; 
     OnCounterChanged(EventArgs.Empty); 
    } 

    protected virtual void OnCounterChanged(EventArgs args) 
    { 
     if (CounterChanged != null) 
     CounterChanged(this,args); 
    } 

    public event EventHandler CounterChanged; 
} 

Los controladores de eventos pueden lanzar una excepción, incluso si IncreaseCounter completado con éxito el cambio de estado. Así que no tenemos una fuerte exception safety aquí:

La garantía fuerte: que la operación ha completado con éxito, ya sea o iniciado una excepción, dejando el estado del programa exactamente como imperante antes del inicio de la operación.

¿Es posible tener una fuerte excepción de seguridad cuando necesita eventos?

Answer 1

Para evitar una excepción en un manejador se propaguen al generador de eventos, la respuesta es invocar manualmente cada elemento en el Delegado MultiCast (es decir, el controlador de eventos) dentro de un try-catch

Se llamarán todos los manejadores, y la excepción w no propagar

public EventHandler<EventArgs> SomeEvent; 

protected void OnSomeEvent(EventArgs args) 
{ 
    var handler = SomeEvent; 
    if (handler != null) 
    { 
     foreach (EventHandler<EventArgs> item in handler.GetInvocationList()) 
     { 
      try 
      { 
       item(this, args); 
      } 
      catch (Exception e) 
      { 
       // handle/report/ignore exception 
      } 
     }     
    } 
} 

lo que queda es para que usted pueda implementar la lógica de lo que hagas cuando uno o más destinatarios de eventos tiros y los otros no lo hacen. El catch() también podría detectar una excepción específica y revertir cualquier cambio si eso es lo que tiene sentido, permitiendo que el destinatario del evento señale al origen del evento que se ha producido una situación excepcional.

Como otros señalan, no se recomienda utilizar excepciones como flujo de control. Si es realmente una circunstancia excepcional, entonces use una excepción. Si recibe muchas excepciones, probablemente quiera usar otra cosa.

Answer 2

¿No cambiará simplemente el orden de las dos líneas en IncreaseCounter enforcestrong excepción de seguridad para usted?

O si lo necesidad para incrementar Counter antes de levantar el evento:

public void IncreaseCounter() 
{ 
    this.Counter += 1; 

    try 
    { 
     OnCounterChanged(EventArgs.Empty); 
    } 
    catch 
    { 
     this.Counter -= 1; 

     throw; 
    } 
} 

En una situación en la que usted tiene cambios de estado más complejas (efectos secundarios) en marcha, entonces se convierte en algo más complicada (es posible que tenga que clonar ciertos objetos, por ejemplo), pero para este ejemplo, parecería bastante fácil.

Answer 3

El patrón general verá los marcos es:

public class Example 
{ 
    public int Counter { get; private set; } 

    public void IncreaseCounter() 
    { 
     OnCounterChanging(EventArgs.Empty); 
     this.Counter = this.Counter + 1; 
     OnCounterChanged(EventArgs.Empty); 
    } 

    protected virtual void OnCounterChanged(EventArgs args) 
    { 
     if (CounterChanged != null) 
     CounterChanged(this, args); 
    } 

    protected virtual void OnCounterChanging(EventArgs args) 
    { 
     if (CounterChanging != null) 
     CounterChanging(this, args); 
    } 

    public event EventHandler<EventArgs> CounterChanging; 
    public event EventHandler<EventArgs> CounterChanged; 
} 

Si un usuario desea lanzar una excepción para evitar el cambio de valor, entonces debe hacerlo en el OnCounterChanging() evento en vez del OnCounterChanged(). Por definición del nombre (tiempo pasado, sufijo de -ed) que implica que el valor ha sido cambiado.

Editar:

Tenga en cuenta que por lo general desea permanecer lejos de grandes cantidades de try..catch extra/bloques finally como controladores de excepciones (incluyendo try..finally) son caros dependiendo de la implementación del lenguaje. es decir, el modelo enmarcado win32 o el modelo de excepción mapeado en PC tienen sus pros y sus contras; sin embargo, si hay demasiados marcos, ambos serán costosos (ya sea en espacio o velocidad de ejecución). Simplemente otra cosa a tener en cuenta al crear un marco.

Answer 4

En este caso, creo que debería seguir el ejemplo de la Fundación Workflow. En el método OnCounterChanged, rodee la llamada al delegado con un bloque genérico try-catch. En el controlador de capturas, tendrás que hacer lo que efectivamente es una acción de compensación: retroceder el contador.

Answer 5

Bueno, se podría compensar si era crítico:

public void IncreaseCounter() 
{ 
    int oldCounter = this.Counter; 
    try { 
     this.Counter = this.Counter + 1; 
     OnCounterChanged(EventArgs.Empty); 
    } catch { 
     this.Counter = oldCounter; 
     throw; 
    } 
} 

Obviamente, esto sería mejor si se puede hablar con el campo (ya que la asignación de un campo no lo hará de error).También podría terminar con esto en bolierplate:

void SetField<T>(ref T field, T value, EventHandler handler) { 
    T oldValue = field; 
    try { 
     field = value; 
     if(handler != null) handler(this, EventArgs.Empty); 
    } catch { 
     field = oldField; 
     throw; 
    } 
} 

y llame:

SetField(ref counter, counter + 1, CounterChanged); 

o algo similar ...