Wozu Exception Objects

[Rolf B]

Hallo pl,

eigentlich hast Du alles genannt bekommen:

• sauberere Datenorganisation
• Polymorphie bei der Fehlerbehandlung
• Klassifikationsmöglichkeit der Fehlerursache

Gerade zum letzten Punkt gerne noch ein Beispiel: Bei uns im Unternehmen verwenden wir eine Middleware, um aus C# Programmen auf unseren Großrechner zuzugreifen. Wenn es dabei zu Problemen kommt, gibt es eine Exception. Eine davon ist speziell, sie sagt mir: Das hat länger gedauert als Du warten wolltest. Eine andere sagt mir: Dein User darf diesen Service aber gar nicht nutzen. Und noch andere: Da ist Schrott in der Servicedefinition, der Service ist platt, der Message Queue Dienst ist im Eimer - jede Menge.

Bei den meisten reicht der Meldungstext, klar. Aber die Reaktion ist trotzdem verschieden:

• Schrott, Service platt, MQ im Eimer -> ich kann gar nichts mehr tun, der Anwender muss warten bis das System wieder läuft
• Recht fehlt: Kann man ausnutzen um zu unterscheiden, was der Mensch eigentlich tun darf.
• Timeout: Hier bekomme ich als zusätzliches Property einen AsyncKey, also eine Objektreferenz, mit dem ich einen Lookup-Call machen kann, um - ggf. nach Rückfrage an den Anwender - länger zu warten.

Das Ganze passiert dann auf einem Webserver-Pärchen, das eben mal 5000 Anwender bedient, also locker 100 Requests pro Sekunde abarbeiten muss. Das passiert in etlichen Threads parallel auf einem Multicore-Server. Da ist nichts mit statischen Variablen, alles muss auf Stack oder Heap liegen. Ohne Exception-Objekte bekäme ich Kontextinformationen zu ausgelösten Exceptions nicht durch den Callstack nach oben.

Und durch die Typen der Exception-Objekte kann ich im catch schon kategorisieren. Zusammen mit when kann ich erreichen, dass überhaupt nicht erst gefangen wird, wenn die Bedingung falsch ist (was beim Stacktrace einen Unterschied macht).

try {
   var result = fooService.BarMethod(x,y,z);
   // result verarbeiten
}
catch (TimeoutException te) when te.RetryCount < 3 {
   // Spezielle HostAccessException bei Timeout, ggf. mittels te.AsyncKey weiter warten
   // where-Option fängt die Exception nur wenn re
}
finally {
   // Abräumen etc
}

Rolf