Clean Code

[MrScoville]

Nimm doch Exceptions als Events hin, und schon wird alles gut. Google nach Ralf Westphal und Event Based Components. In einer Umgebung wie etwa .NET sind Events und Exceptions quasi dasselbe, wenn man sie entsprechend behandelt, weil die Laufzeit das so her gibt. PHP kann das aber auch. Der Clou ist, dass du dich mal von Use Cases und Begrifflichkeiten trennst in deinem Kopf und dich auf Ergebnisse konzentrierst.

Angenommen, ein Wert kann nicht ermittelt werden. Dann ist es völlig egal, wo er her hätte stammen sollen, ob nun aus einer lokalen Datei, aus einer Methode, einem JSON Gedöns... Er ist halt nicht da. Ob das nun durch Exceptions oder sonstwas mitgeteilt wird, ist china. Genau an dem Punkt, wo der Wert gebraucht würde, muss man mit dem Umstand nun klug umgehen, und zwar mit dem Fehlen des Werts, nicht mit der Ursache, Das ist wie bei der Bahn: dem Fahrgast ist es ebenfalls china, ob die Lok kaputt ist oder sich ein Hirsch vor den Zug geschmissen hat, es interessiert ihn nicht einmal, ob der Zug eine Stunde später kommt oder ein Ersatzzug, sondern nur, wann er weiter fahren kann und wann er dann schließlich ankommt. Dass man in den beteiligten Methoden für den Administrator einen Log-Eintrag schreibt und ihn benachrichtigt, ist eine ganz andere Baustelle ("cross cutting concern").

Wie lottikarotti es perfekt beschrieben hat: Ob nun ein XYZ das abc-Verhalten intern implementiert oder du da eine Form der 12345 nutzt, ist dir überlassen und für das Thema "Clean Code" auch erstmal völlig egal. Wichtig ist nur dass keine Abhängigkeiten zwischen Ebenen hergestellt werden, die eigentlich nichts voneinander wissen.

Ich würde es ohne Ebenen noch etwas deftiger formulieren, ganz im Sinne der EBCs und darüber weit hinaus: Wichtig ist, dass du keine unnötigen Abhängigkeiten zwischen Komponenten herstellst. Punkt.

[JaMa]

Angenommen, ein Wert kann nicht ermittelt werden. Dann ist es völlig egal, wo er her hätte stammen sollen, ob nun aus einer lokalen Datei, aus einer Methode, einem JSON Gedöns... Er ist halt nicht da. Ob das nun durch Exceptions oder sonstwas mitgeteilt wird, ist china.

Wenn es sich beim Fehlen des Wertes um einen Ausnahmefall (z.B. API nicht erreichbar) handelt, dann muss man das auch so behandeln (Exception) und nicht über etwas anderes (Event).

Wobei du bei einem EventSystem ja genau so vorgehen müsstest wie bei Exceptions. Irgendwo musst du ja die Events auch weiterreichen und um keine Abhängigkeiten zu anderen Ebene zu schaffen diese auch abstrahieren (ergo "neu verpacken").

[MrScoville]

Wenn es sich bei (...) um einen Ausnahmefall (...) handelt, dann muss man das auch so behandeln (Exception) und nicht über etwas anderes (Event).

Wobei du bei einem EventSystem ja genau so vorgehen müsstest wie bei Exceptions.

Du hast es (im zweiten Satz) ja doch verstanden. Nur, weil es Exception heißt, ist es noch lange nichts anderes als ein Event. Der Unterschied liegt nicht im Namen, sondern bei der Person, die die Behandlung implementiert. Benamen wir es doch einmal um: "Expected Event" vs. "Unexpected Event". Wenn man seine Software grundsätzlich asynchron implementiert, verwischt der Unterschied ansonsten noch viel mehr, denn dann schlagen Exceptions ebenfalls asynchron auf, eben genau so wie Events. Und dann greift, um nach langer Zeit mal wieder eines der hübschen Abkürzungen aus der Clean Code-Schublade zu ziehen: KISS.

Zum Grübeln: Ist das unangekündigte Rausziehen einer Festplatte aus einem Blade-System ein Event oder eine Exception, wenn das OS gerade darauf schreibt? Was sollte dann passieren? Eine Meldung, dass du gerade Platte 3:1 gezogen hast und die Operation deswegen nicht abgeschlossen werden konnte? Ein Log-Eintrag? Oder einfach ein Rollback im Cache-System ohne jede Meldung und ein erneuter Versuch, wenn das Dateisystem wieder beieinander ist? Ist keine Clean Code-Regel, aber mir gefällt die Abkürzung: DMU! "Don't Molest Users!"

[JaMa]

Was machst du denn wenn in einer Methode ein Fehler auftritt (dein angenommener I/O Fehler)?
Wie verlässt du nach auslösen des Events die Methode? Wenn du irgendeinen oder keinen Wert zurückgibst (obwohl einer erwartet wird), musst du das in der aufrufenden Ebene explizit abfragen. Wie könntest du dann hier unterscheiden zwischen unerwarteten Fehlern und erwarteten Fehlern unterscheiden?

Zu deiner Grübelaufgabe:
1) Die Kompetenz des entsprechenden Mitarbeiters in Frage stellen
2) Kann ich so pauschal nicht sagen. Kommt ja darauf an was ich auf die Platte schreiben möchte. Generell würde ich natürlich versuchen den Benutzer soweit es geht rauszuhalten (nach deinem "DMU"), geht es aber nicht anders, so muss dieser eben zumindest benachrichtigt werden.

[erc]

Wie du das im Detail implementierst hängt von deiner Anwendung ab.

Ich suche auch keine Lösungsansatz, das ist ein fiktives Problem ohne Kontext. Was mich interessierte war das Exception Handling bei Clean Code. Darauf hab ich auch eine Antwort. Im Prinzip müsste jede Ebene pauschal eigene Exceptions implementieren, damit höhere Ebenen darauf reagieren "dürfen". Wird das in der Praxis so gemacht? In Kreis der Antworter scheinbar nicht.

Nimm doch Exceptions als Events hin, und schon wird alles gut. Google nach Ralf Westphal und Event Based Components. In einer Umgebung wie etwa .NET sind Events und Exceptions quasi dasselbe, wenn man sie entsprechend behandelt, weil die Laufzeit das so her gibt. PHP kann das aber auch. Der Clou ist, dass du dich mal von Use Cases und Begrifflichkeiten trennst in deinem Kopf und dich auf Ergebnisse konzentrierst.

Vielen Dank für diese Sicht. 1. Ich arbeite immer ergebnisorientiert. 2. Das machts nicht unbedingt klarer. Ersetzte ich Exceptions gegen Events lautet die Frage immer noch "Kapselst du die Events auf jeder Ebene?". Mit Clean Code ist ziemlich genau festgelegt welche Ebenen komunizieren. Wenn das Repository als Event sagt "Bestellung nicht angelegt" aka Exception oder "Bestellung angelegt Nr.232". Dann hat das in dem Beispiel noch die Use Case Klasse zu interessieren, alles nachfolgende nicht mehr. Die Use Case Klasse müsste die Events selbst feuern/kappseln damit die nchfolgende Ebene sie nutzen kann.

[ChristianK]

Du hast es (im zweiten Satz) ja doch verstanden. Nur, weil es Exception heißt, ist es noch lange nichts anderes als ein Event. Der Unterschied liegt nicht im Namen, sondern bei der Person
Zum Grübeln: Ist das unangekündigte Rausziehen einer Festplatte aus einem Blade-System ein Event oder eine Exception, wenn das OS gerade darauf schreibt? Was sollte dann passieren? Eine Meldung, dass du gerade Platte 3:1 gezogen hast und die Operation deswegen nicht abgeschlossen werden konnte? Ein Log-Eintrag? Oder einfach ein Rollback im Cache-System ohne jede Meldung und ein erneuter Versuch, wenn das Dateisystem wieder beieinander ist? Ist keine Clean Code-Regel, aber mir gefällt die Abkürzung: DMU! "Don't Molest Users!"

Da gibt es eine klare Trennung: ein Event ist ein Vorkommnis, eine Exception ein zustand, in dem weiterarbeiten unmöglich ist.

Exceptions dürfen nie zum Steuern des Ablaufs verwendet werden.

Um auf dein Beispiel zurückzukommen: ist die Platte Teil eines Raids, ist es ein event, da noch weiter gearbeitet werden kann. Ist es die alleinige Platte, ist es eine Exception, da kein weiterarbeiten möglich ist.