Short tasks vs. Long tasks 11/2010

[Werner Mairl]

Hallo zusammen!

Keine Ahnung ob das wer liest, scheint ja gewaltig viel los zu sein in diesem Forum, aber ich hab mich grad über einen Codeabschnitt in Ihrer aktuellen Ausgabe ziemlich geärgert, da muss ich mir jetzt Luft machen ;-)

Also, es geht um den Artikel
"Short tasks vs. Long tasks" in Ausgabe 11/2010 des .Net Magazins
Seite 54, Listing 2 die Methode "Execute"
(Ich erspar mir jetzt das Abschreibendes Codes, falls sich eine Diskussion ergibt darf das jeder der im Besitz der Sourcen ist gerne übernehmen)

Diese Methode hat einen ganz schweren Design Fehler:
JEDE Art von Exception wird in eine ArgumentException umgewandelt, und der Stacktrace abgeschnitten

Ausserdem ist die try/Finally Verwendung für den OverrideCursor mehr als Suboptimal gelöst.

Ich weiss aus eigener Erfahrung (auch als Autor), dass man das Thema Exceptionhandling in vielen Beispielen aus Übersichtsgründen komplett weglässt, das finde ich ja noch OK!

Aber wenn man ein Beispiel mit Exceptionhandling veröffentlicht, in welchem es zum Teil explizit um dieses Handling geht (Cursor/Try/Catch/Finally Handling) dann sollte der Code wenigstens keine OFFENSICHTLICHEN Fehler enthalten.

Speziell wenn man sich im Abspann des Artikels noch damit brüstet, dass dieser Code einen Innovation Award gewonnen hat

Schöne grüße
Werner Mairl

PS.: Ja, das ist mein erstes Post in diesem Forum, aber dafür stehe ich auch mit meinem Realname dafür ein

[Risto Kyburz]

AW

Guten Tag Herr Mairl

Ich wurde von der .NET-Magazin Redaktion gestern auf Ihren Forum-Eintrag aufmerksam gemacht und habe diesen somit erst jetzt gesehen, ansonsten hätte ich Ihnen selbstverständlich schon lange zurück geschrieben.

Der Artikel behandelt die Abarbeitung von synchronen und asynchronen Tasks im .net WPF Umfeld mit der Verwendung des MVVM Patterns. Die Idee bestand darin, eine synchrone Abarbeitung eines Tasks mit einer asynchronen Abarbeitung eines Tasks gegenüber zu stellen.

Bei der asynchronen Abarbeitung wird der Benutzer mittels „ProgressBars“ informiert in welchem Status sich der Task befindet. Bei der Implementation des synchronen Tasks kann dies z.B. mittels des „WaitCursers“ umgesetzt werden, da der Tasks ja schnell abgearbeitet sein sollte. So habe ich dies für diesen Beispiel Code mittels dieser Exception gelöst, vor allem um aufzuzeigen, dass nach meiner Ansicht das Handling des „WaitCursers“ in dieser Methode stattfinden kann (da das Command vom UI aus gestartet wird und somit ein Model Command startet). Mir ist aber bewusst, und durch Ihren Kommentar erst recht , dass dies nicht den „Best Practicen“ eines Exception Handlings entspricht und subotimal umgesetzt ist! Da es sich ja um ein kontextfreien Code Abschnitt handelt, fand ich die Implementation für diesen Demo Zweck legitim (um Aufzuzeigen, wie ein solches Command aufgebaut sein kann).

Bei einem nächsten Wurf eines solchen Code Abschnitts würde ich das Exception Handling weglassen oder durch ein anderes, z.B. eines durch einem konstruktiven Vorschlag Ihrerseits codierten, ersetzen.

Besten Dank fürs Feedback und schöne Grüsse
Risto Kyburz