Funktion als Exception markieren?

[himitsu]

Fehlerbehandlung in eine Prozedur ausgelagert und schon fängt der Spaß an, weil überall der Compiler mit Warnungen um sich schmeißt, welche "eigentlich" garnicht stimmen.

Wen hat das noch nicht genervt? (voten wenn ja, wäre bestimmt nett)

https://quality.embarcadero.com/browse/RSP-38882


Es gibt ja viele Sprachen, wo man zumindestens für die Dokumentation
und teilweise auch für die Fehlerbehandlung
zu seinen Funktionen irgendwie angeben kann ob und welche Exceptions zu erwarten sind, wenn man jene Methode ausführt.



PS:
https://quality.embarcadero.com/browse/RSP-18827
https://quality.embarcadero.com/browse/RSP-26129
https://quality.embarcadero.com/browse/RSP-16508

[Der schöne Günther]

Zitat von himitsu:

Es gibt ja viele Sprachen, (...) angeben kann ob und welche Exceptions zu erwarten sind,

Das vermisse ich von Java wirklich am meisten.
Vielleicht auch als einziges. Aber das war wirklich immer klasse - Das wurde nicht zur Info angegeben, sondern der Aufrufer muss die Exception behandeln. Sonst wirft der Compiler dir das um die Ohren und sagt "Hey, hier kann eine FileNotFoundException auftreten, behandelst du die bitte?"

[himitsu]

Ein bissl Java ist im Delphi auch drin ... das muß auch GAAAAANZ viel sein, denn Jira will bei Quellcode immer zuerst {code:java} und man muß es selber nach delphi oder cpp umschreiben.

[TurboMagic]

Zumindest per XMLDOC müsste es ab Delphi 11.1 gehen.
Habe aber den Namen des Tags vergessen...

[Uwe Raabe]

Code:

/// <exception cref="ENotSupported">
///   Sender = nil
/// </exception>

Aber das keinen Einfluss auf den Compiler.

[himitsu]

Ja, das gibt es einen Tag. Den müsste man unschön in der Code-Completion den Code-Templates finden können.

Und Documentation Insight (Werbung) kann noch bissl mehr und schöner.


Aber dem Compiler sind diese "Kommentare" leider Scheißegal.
(der müsste ja erstmal deren Inhalt mit parsen, bzw. er braucht eher [Attribute] oder eben Direktiven)

[Dennis07]

Zitat von himitsu:

Fehlerbehandlung in eine Prozedur ausgelagert und schon fängt der Spaß an, weil überall der Compiler mit Warnungen um sich schmeißt, welche "eigentlich" garnicht stimmen.

Wie soll der Compiler das denn bitte checken können? Also möglich wäre sowas natürlich, aber sehr, sehr aufwändig. Du musst ja alle Programmpfade durchgehen und prüfen, ob sicher überall eine Exception geworfen wird. Und das bei CodeInsight bzw. LSP, was ja eh schon kaum vernünftig läuft und ständig abschmiert.

Zitat von himitsu:

Es gibt ja viele Sprachen, (...) angeben kann ob und welche Exceptions zu erwarten sind,

Joa, das stimmt. Und das zu validieren ist ja auch kein Hexenwerk. Aber das hilft hier in dem Szenario ja nicht weiter, weil es hier ja nicht darum geht, ob eine Exception geworfen werden könnte, sondern es geht darum, ob eine Exception geworfen werden muss.

Zitat von Uwe Raabe:

Code:

/// <exception cref="ENotSupported">
///   Sender = nil
/// </exception>

Aber das keinen Einfluss auf den Compiler.

Das hat bis 11.2 auf überhaupt gar nichts einen Einfluss, weil die XML-Hilfen ja seit Jahren nicht mehr richtig funktionieren ( -> funktioniert haben, wurde jetzt gefixt). Außerdem, wie oben beschrieben, hilft das ja nicht zu bestimmen, ob sicher ein Fehler geworfen wird.

[himitsu]

Zitat von Dennis07:

Wie soll der Compiler das denn bitte checken können? Also möglich wäre sowas natürlich, aber sehr, sehr aufwändig. Du musst ja alle Programmpfade durchgehen und prüfen, ob sicher überall eine Exception geworfen wird. Und das bei CodeInsight bzw. LSP, was ja eh schon kaum vernünftig läuft und ständig abschmiert.

Na so, wie jetzt auch schon?

Gibt es keinen Pfad, der bis zum END führt, oder bei einem EXIT endet,
bzw. gibt es ausschließlich Pfade, die bei einer Exception, Abort oder einer "mit exception" markierten Methode ankommen,
dann ist es so.

Und es muß nur noch an der Funktion gespeichert werden, dass es so ist, damit bei Verwendung/Aufruf das abgefragt werden kann.

[Dennis07]

Ja okay, wie gesagt, möglich ist es ja. Zumindest, wenn man jetzt mal von ASM-Abschnitten, Zeigern, Labels/GoTos und OS-Fehlern absieht. Diese Sachen kann man halt nicht zuverlässig vorhersagen, aber das wird ja bei keiner der Warnungen auch nur versucht.
Aber ja, du hast wohl recht, wenn man das mit in den Methoden-Cache packt, dann ginge das schon ohne zu viel Overhead.

[himitsu]

Alternativ, eben, wie hier ursprünglich "gewünscht", dass der Entwickler es einfach manuell setzt.
Wenn der Code dann doch keine Exception auslöst, dass ist es einfach ein Fehler.

So als Option an die Deklaration.
Attribute oder eben so wie inline/virtual/abstract/cdecl/...