Michiel van Otegem, IT Composer

Thursday, September 01, 2005

Ook guidelines zijn niet altijd goed

Vandaag kwam ik terecht op een pagina waarop staat hoe je volgens Microsoft classes moet implementeren die een event bieden. De pagina in kwestie How to: Create Events that Conform to .NET Framework Guidelines (C# Programmers Reference) komt uit de (pre-release) documentatie van .NET 2.0, en staat ook in de reference voor WinFx. De guideline zegt dat als je class een event aanbiedt deze er als volgt uit moet zien (het gaat hier om het Changed event):

// An event that clients can use to be notified whenever the
// elements of the list change:
public event EventHandler Changed;

// Invoke the Changed event; called whenever list changes:
protected virtual void OnChanged(EventArgs e)
{
if (Changed != null)
   Changed(this,e);
}

Pop Quiz: Wat is hier mis mee?
Hint: Stel je eens voor wat er gebeurt in een van de geregistreerde event handlers een fout optreedt die niet afgehandeld wordt.

Antwoord (tekst is wit, dus even selecteren):
Als in een van de event handlers een fout optreedt, zullen alle nog niet uitgevoerde event handlers nooit uitgevoerd worden, en krijg je een glasharde unhandled exception (=crash). Nu kun je natuurlijk een try-catch block gebruiken om die unhandled exception af te vangen, maar dan hou je dat de nog niet uitgevoerde event handlers niet uitgevoerd worden. In de meeste gevallen is er maar één event handler, dus maakt het nog niet uit, maar het gaat om het principe. Als je verwacht dat meerdere event handlers geregistreerd worden, dan moet je de geregistreerde delegates zelf af gaan, als volgt:

protected virtual void OnChanged(EventArgs e)
{
   if (Changed != null)
   {
      foreach (EventHandler handler in Changed.GetInvocationList())
      {
         try
         {
            handler(this, e);
         }
         catch
         {
            continue;
         }
      }
   }
}



In dit geval ben ik even lui geweest en ga ik bij een fout gewoon door naar de volgende event handler, maar je kunt daar uiteraard ook foutafhandeling toevoegen.

1 Comments:

  • Juist ik heb dit pas toegepast in een Service die events afvuurt. Ik logde de foutmeldingen die door listeners gegenereerd werden en zorgde ervoor dat de functie in de clients (listeners) verbeterd werden zodat deze fouten niet meer konden optreden. Het is een goed voorbeeld van defensief programmeren.

    Herman van der Blom - MSCD

    By Anonymous Anonymous, at 23 May, 2006 16:06  

Post a Comment

<< Home