Ist eine Ausnahme eine gültige Nachbedingung?

Question

Betrachten Sie die folgende Schnittstelle:

public interface AISPI 
{ 
    public Path getPath(Entity entity, Entity target, World world) throws NoPathException; 
} 

Zugegeben, dass Einheit, Ziel und Welt alle gültige Eingabe sind. Aber der Algorithmus, der verwendet wird, um einen Pfad zu finden (in diesem Fall Astar), findet keinen Pfad, z. die Position Ziel wird von Betonwänden umgeben.

Ist es gültig zu erklären, dass die Nachbedingung entweder ein Pfad von Einheit-Ziel (Start zum Ziel) oder eine NoPathException (vorausgesetzt, dass ein Weg gefunden wurde nicht) ist?
- Oder sollte die Vorbedingung angeben, dass ein gültiger Pfad vom Start zum Ziel vorhanden sein muss?

Dies sind keine Hausaufgaben, sondern eine Frage zur Verbesserung unseres Semesterberichtes. Ich möchte keine Rahmenbedingungen kennenlernen, es handelt sich lediglich um eine Frage von Standards und Formalitäten in Bezug auf die Vertragsgestaltung. Danke für die Klärung der Angelegenheit.

Answer 1

Es hängt von der Definition des Begriffs nach Bedingung ab. Im Allgemeinen ist eine Vorbedingung eine Relation für den Eingabezustand und die Eingabewerte bei der Routineeingabe, und eine Nachbedingung ist eine Beziehung für den Eingabezustand, die Eingabewerte und den Ausgabezustand und die Ausgabewerte beim Routine-Exit.

Da eine Routine entweder normal oder ausnahmsweise beendet werden kann, ist es möglich, eine Nachbedingung für eine normale Beendigung und eine Nachbedingung für eine abnormale Beendigung zu definieren. Offensichtlich sind beide Eingabewerte, der Eingabezustand und der Ausgabezustand. Der Hauptunterschied liegt in den Ausgabewerten. Im ersten Fall ist dies ein Wert, der in der Routinensignatur angegeben wird, in der zweiten - er hängt von der Sprache ab. In Ihrem Beispiel könnte es NoPathException sein, aber was ist, wenn es einen Speicherzuweisungsfehler, einen Stapelüberlauf oder eine andere Ausnahme oder ein Signal gibt, das nicht in der Signatur spezifiziert ist? Es scheint tatsächlich möglich zu sein, eine Vorbedingung zu haben, die garantiert, dass es immer ein gültiges Ergebnis gibt, das keine Ausnahmen beinhaltet. Dies ist jedoch nicht der Fall, z.B. wenn es eine Kommunikation mit der Außenwelt, Nebenläufigkeit usw. gibt. Auch wenn eine Vorbedingung zu kostenaufwendig ist, sieht es nicht gut aus, die gleiche Arbeit zweimal zu tun - auf der Clientseite, um sicherzustellen, dass ein Anruf anwendbar ist und auf Seiten des Anbieters im Wesentlichen die gleiche Berechnung zu tun, um das Ergebnis zu erhalten.

Gemäß der Design by Contract Philosophie eine Nachbedingung ist, was der Client sicher nach dem Aufruf einer Routine verlassen kann. Zurückkommend auf den Ausnahmefall, ist es aus praktischer Sicht sinnvoll, die abnormale Nachbedingung stark genug zu machen, damit ein Programm die Ausführung fortsetzen kann, aber schwach genug, so dass die Fälle, die nicht in der Signatur angegeben sind oder können, aber sind in der Praxis möglich, sind erlaubt.

Wenn also die Sprache nicht wirklich alle möglichen Ausnahmefälle und nichts anderes garantiert, ist der wichtigste Teil der Ausgabezustand, der die zugehörigen Objekte nicht unbrauchbar machen sollte. Und dies könnte entweder in einer expliziten oder impliziten Nachbedingung oder als Klasseninvariante ausgedrückt werden.

Bezüglich des spezifischen Beispiels mit getPath ist die Situation, wenn ein Pfad nicht existiert, normal, d.h. es kann vorkommen, wird erwartet. Einige Richtlinien empfehlen, normale Werte zu verwenden, um normale Beendigungsfälle anzuzeigen. Hier wäre der Wert null.Die Verwendung von null kann zu anderen Problemen auf der Seite des Aufrufers führen, wie NullPointerException, wenn das Ergebnis nicht auf Null-Nichtigkeit geprüft wird, aber in einigen Sprachen, die das Fehlen solcher Ausnahmen garantieren (z. B. void-safety in Eiffel) bevorzugte Möglichkeit, die Abwesenheit eines Pfades anzugeben (der Rückgabetyp wäre in diesem Fall detachable PATH).