In einigen Delphi 7-Code, den ich behalte, habe ich eine Menge folgender Fälle bemerkt:
%Vor%Es scheint mir, dass diese try Blöcke entfernt werden könnten, da sie nichts tun. Ich bin jedoch vorsichtig mit möglichen subtilen Nebenwirkungen ..
Kann irgendjemand an irgendwelche Fälle denken, in denen diese Blöcke tatsächlich etwas tun könnten, was ohne sie dort nicht passieren würde?
In diesem Kontext hat die Raise-Operation keine Wirkung und sollte entfernt werden, da sie einfach die Ausnahme wieder aufruft, die der Ausnahmeblock gerade gefangen hat. Raise wird normalerweise verwendet, um die Kontrolle an das Ende des Blocks zu übertragen, wenn keine geeignete Fehlerbehandlung verfügbar ist. Im Folgenden behandeln wir die benutzerdefinierte Ausnahme, aber jede andere Ausnahme sollte anderswo behandelt werden.
%Vor%Achten Sie darauf, dass es eine ähnlich aussehende Form ohne "Raise" gibt, die den Nebeneffekt des Essens / Verbergens von Ausnahmen hat. Praktiken von sehr skrupellosen Entwicklern, die hoffentlich zu Positionen im Wettbewerb gewechselt haben.
%Vor%Okay, wirklich zwei Fragen hier.
Erstens ist es ist bedeutungsvoll: Wenn execSQL eine Ausnahme auslöst, wird es vom try-Block abgefangen und an das except weitergeleitet. Dann wird es durch die Erhöhung zum nächsthöheren Block weitergeleitet.
Zweitens, ist es nützlich ? Wahrscheinlich nicht. Es ist fast sicher das Ergebnis eines von drei Dingen:
execSQL -Statement gemachten Ausnahmen in eine andere, aussagekräftigere Ausnahme umwandeln. Ich habe vielleicht ein bisschen schnell geantwortet, siehe am Ende ...
Wie es ist, ist es für die Anwendung nutzlos .
Zeitraum!
Jetzt auf der "warum" -Seite. Es kann sein, die Ausnahmebehandlung zu standardisieren, wenn / an anderen Stellen / ist / ist / ist / ist / irgendeine Art von Protokollierungscode, der vor der Erhöhung eingefügt wurde:
%Vor%oder für Cleanup-Code:
%Vor% Update : Es würde einen Fall geben, in dem ich etwas genau so sehen würde, wie es ist ...
... um einen Haltepunkt in die raise -Zeile einzufügen, um eine Chance zu bekommen, zu sehen, was im Kontext dieses Code-Blocks vor sich geht.
Dieser Code tut nichts anderes, als dem ursprünglichen Programmierer zu erlauben, einen Haltepunkt auf dem 'Raise' zu setzen und die Ausnahme näher in der Quelle zu ihrer möglichen Ursache zu sehen. In diesem Sinne ist es eine absolut vernünftige Debugging-Technik.
Eigentlich sollte ich dies als Kommentar zu François 'Antworten posten, aber ich weiß nicht, ob es möglich ist, dort formatierten Code einzufügen :( Ich poste das als Antwort.
2mghie:
Der zweite ist völlig unidiomatisch, würde man stattdessen stattdessen verwenden.
Nein, "finally" reinigt das Objekt immer. "Außer" - nur bei Ausnahme. Betrachten Sie den Fall der Funktion, die ein Objekt erstellt, füllt und zurückgibt:
%Vor%Wenn Sie "finally" dort setzen - Funktion wird immer nil zurückgeben. Wenn Sie den "try" -Block überhaupt nicht angeben, werden im Falle einer Ausnahme in "..." Ressourcen auslaufen.
P.S. Natürlich können Sie "finally" verwenden und ExceptObj überprüfen, aber ... ist das nicht hässlich?
Der Titel enthält eine ziemlich breite Frage, während seine Erklärung ein konkreteres Beispiel gibt. Also, meine Antwort auf die Frage, wie es von dem Beispiel ausgeht, kann zweifelhaft etwas Nützliches hinzufügen, was bereits hier gesagt wurde.
Aber vielleicht möchte Blorgbeard tatsächlich wissen, ob es überhaupt sinnvoll ist, try ... except raise; end . Wenn ich mich in Delphi 7 richtig erinnere, würde Exit den finally -Teil eines try-finally Blocks auslösen (als wäre es eine Art Ausnahme). Jemand könnte ein solches Verhalten für seine Aufgabe als ungeeignet betrachten, und die Verwendung der betreffenden Konstruktion ist eine echte Umgehungslösung.
Nur wäre es immer noch seltsam, dort ein einziges raise; zu verwenden, aber dann hätten wir lieber über Nützlichkeit als über Sinnhaftigkeit gesprochen, wie Charlie genau beobachtet hat.
Dieser Code tut nichts anderes, als eine Ausnahme erneut auszulösen, die bereits ohne diesen Versuch außer block ausgelöst wird. Sie können es sicher entfernen.