Ist die Ausnahmebehandlung ein Querschnittsthema?

Ich sehe keinen großen Unterschied zwischen den Belangen der Ausnahmebehandlung und der Anmeldung, da beide übergreifende Belange sind. Was denkst du? Sollte es nicht separat gehandhabt werden, anstatt mit der Kernlogik, die eine Methode implementiert, verschachtelt zu sein?

EDIT : Ich versuche zu sagen, dass eine Methodenimplementierung meiner Meinung nach nur die Logik für den erfolgreichen Ausführungspfad enthalten sollte und Ausnahmen an anderer Stelle behandelt werden sollten. Hierbei handelt es sich nicht um aktivierte / deaktivierte Ausnahmen.

Beispielsweise kann eine Sprache Ausnahmen vollständig überprüft behandeln, indem sie Konstrukte wie das folgende verwendet:

class FileReader {

  public String readFile(String path) {
    // implement the reading logic, avoid exception handling
  }

}

handler FileReader {

   handle String readFile(String path) {
      when (IOException joe) {
        // somehow access the FileInputStram and close it
      }
   }

}

In der oben genannten konzeptionellen Sprache wird das Programm ohne FileReader Handler nicht kompiliert , da die readFile-Datei der FileReader Klasse keine Ausnahme auslöst. Indem der FileReader Handler deklariert wird , kann der Compiler sicherstellen, dass er behandelt wird, und das Programm wird dann kompiliert.

Auf diese Weise haben wir sowohl bei aktivierten als auch bei nicht aktivierten Ausnahmeproblemen das Beste: Robustheit und Lesbarkeit.

In einigen Fällen ja

In den Fällen, in denen Sie eine Ausnahme haben, die protokolliert werden soll (von der ich annehme, dass sie fast immer vorliegt), ist die Ausnahme mit einem Querschnittsthema verbunden.

Meistens nein

Nehmen Sie jedoch die Instanz eines SocketListener. Wenn ein Socketlistener eine Ausnahme auslöst, weil die Verbindung am anderen Ende unterbrochen wird, sollte dies ein vorweggenommenes Verhalten sein und die Anwendung sollte entsprechend den Umständen handeln, die die Ausnahme verursacht haben. Dies ist nichts, was ein generischer Aspekt behandeln sollte, und sollte daher kein Querschnittsthema sein.

Ein Querschnittsthema identifizieren

Wenn Sie denselben Code immer wieder duplizieren, muss er abstrahiert werden. Wenn sich die Abstraktion zu mehreren Ebenen entwickelt, kann dies ein Querschnittsthema sein. Nur dann sollte es in Betracht gezogen werden.

Die Protokollierung ist optional. Ausnahmen behandeln ist nicht.

Die Protokollierung ist ziemlich allgemein und wird, obwohl sie von einer bestimmten Logik stammt, an einen allgemeinen Konsumenten weitergeleitet. Ausnahmen sind immer spezifisch für die Logik, und ein Teil des Codes, der sich mit dieser Logik auskennt, muss mit dem Durcheinander umgehen, das er angerichtet hat.

Zumindest bei meiner eingeschränkten Nutzung der beiden bedeutet dies, dass die beiden Ziele am besten auf unterschiedliche Weise und nicht unter demselben Design-Dach gehandhabt werden.

Ich betrachte die Ausnahmebehandlung als Querschnittsthema für bestimmte Arten von Ausnahmen. Es gibt lokale Ausnahmen, die nur der Code für den sofortigen Aufruf korrekt verarbeiten kann. Ein Beispiel könnte eine Datenbankausnahme sein, wenn versucht wird, eine Abfrage auszuführen. Es gibt jedoch auch Ausnahmen, die globaler gehandhabt werden können und sollten. Ein Beispiel ist möglicherweise eine Ausnahme im Zusammenhang mit fehlenden Sicherheitsanmeldeinformationen (erzwingen Sie die erneute Anmeldung des Benutzers). Oder Sie benötigen zumindest einen globalen Handler, falls eine Ausnahme durch den spezifischeren Code gleitet, um dem Benutzer zu erklären, was er tun soll, um einen Neustart durchzuführen oder ein Protokoll an die IT zu senden oder ähnliches. Für diese Art von global behandelten Ausnahmen ist dies ein Querschnittsthema.

Ich denke, das hängt mit dem Problem der undichten Abstraktionen zusammen.

Viele Ausnahmen sollten abgefangen und erneut geworfen werden, wenn sie durch die Abstraktionsebenen propagieren. Das erneute Auslösen sollte die Ausnahme in einer neuen Form auslösen, die der Abstraktion entspricht, die das erneute Auslösen ausführt, damit es als Teil der Schnittstelle Sinn macht. Mit anderen Worten, Ausnahmen von niedrigeren Abstraktionsebenen sollten in die aktuelle Abstraktionsform übersetzt werden, damit höhere Abstraktionsebenen nicht über die niedrigeren Ebenen Bescheid wissen müssen, auch nicht für die reine Ausnahmebehandlung.

Das "Prinzip der undichten Abstraktionen" ist jedoch ein Thema. Einige Ausnahmen können nicht in eine Form übersetzt werden, die in der nächsten Abstraktionsebene sinnvoll ist.

Eine Ausnahme im Zusammenhang mit dem Netzwerkdateisystem ist ein einfaches Beispiel. Ein Netzwerkfehler kann nicht in Begriffen ausgedrückt werden, die für eine "Datei" -Abstraktion sinnvoll sind, oder wenn dies der Fall ist, kann diese Abstraktion nicht alle Details in Bezug auf die Implementierung der Dateibehandlung vollständig abstrahieren.

Ein Netzwerkausfall würde daher aus der zugrunde liegenden Netzwerkabstraktion austreten und muss daher für den Rest des Codes von übergreifender Bedeutung sein.

Dies gilt jedoch nicht nur für Ausnahmen. Alle diese Rückgabewert-Fehlercodes für Datei-APIs, die sich nicht wirklich auf die Dateiabstraktion beziehen, sondern stattdessen die Festplatte oder das Netzwerk oder welche Fehler auch immer beschreiben, sind in einer anderen Form identisch, was bedeutet, dass Festplatten- und Netzwerkfehler vorliegen usw. sind Querschnittsthemen, unabhängig davon, wie diese Fehler gemeldet werden.