[Nim] Errorhandling

    • Offizieller Beitrag

    Ich habe mich jetzt mal etwas intensiver in das Thema eingelesen. Das Thema ist schon sehr vielfältig. Ich habe jetzt mal ein einfach zu handhabendes Szenario als Bsp. erstellt.

    Grundsätzlich gibt es ja 2 Möglichkeiten:

    a) Ich lasse das Programm/die Funktion in einen Fehler laufen und fange diesen dann ab

    b) Ich prüfe vor Ausführung ob z.B. Parameter fehlerhaft sind und generiere sofort selbst einen Fehler, der dann im Errorhandling weiter bearbeitet wird.

    Hier soll z.B. eine Datei eingelesen werden. Ich prüfe jetzt vorher, ob sie überhaupt existiert und generiere einen Fehler, falls nicht. Wenn Prozeduren Fehler generieren, ist die Art des Fehlers in den entsprechenden Modulen vermerkt (IOError, wImageError, ..). Fehler enden immer auf ..Error.

    Meine Dateiprüfung liefert aber keinen Fehler, sondern true/false. Somit ist es erforderlich einen eigenen Fehlertyp zu erstellen, dem ich dann auch einen entsprechenden Text beim Setzen mitgebe.

    Falls z.B. ein Dateihandle existiert, weil eine Datei zum Schreiben geöffnet wurde und dort ein Fehler auftrat, muss dem "except:" ein "finally:" folgen mit (in diesem Fall) close(f). Wichtig!: Der finally-Zweig wird IMMER ausgeführt (unabhängig ob Fehler oder nicht), also muss diese Aktion auch ausführbar sein und nicht selbst in einen Fehler laufen.

    Doku: Raise & Try

    P.S.

    Falls ihr noch weitere Bsp. zum Errorhandling habt, bitte hier posten. Das Thema ist so komplex, da ist eine Sammlung sicher hilfreich.

  • FileExistsError* = object of Exception # User-exeption, muss auf "..Error" enden!

    So bekomme ich allerdings ein Problem angezeigt...

    Code
    {
        "resource": "/c:/Users/ghost/NIM/@BugFix/FileExistsError.nim",
        "owner": "nim",
        "severity": 4,
        "message": "inherit from a more precise exception type like ValueError, IOError or OSError [InheritFromException]\r\n\r\n",
        "startLineNumber": 4,
        "startColumn": 22,
        "endLineNumber": 4,
        "endColumn": 23
    }

    So geht es ohne Murren...

    Code
    FileExistsError* = object of OSError  # User-exeption, muss auf "..Error" enden!
  • Hab ich eigentlich nicht als Problem verstanden, sondern als reinen Hinweis: "ererbt von einem genaueren Ausnahmetyp wie ValueError, IOError oder OSError"

    Ok, ich habe es anders interpretiert...

    Da die Meldung unter Probleme angezeigt wird und severity (Schweregrad): 4 ist, würde ich es zumindest als Warnung einstufen. Ein reiner Hinweis würde lediglich in der Ausgabe als "Hint: ..." angezeigt werden.

    Jetzt müsste man nur wissen, was severity 4 bedeutet, doch dazu habe ich nichts finden können.

    • Offizieller Beitrag

    Ich habe mal noch eine eigene Form des Fehlermanagements erstellt.

    Man kann zwar super mit try-except innerhalb der Funktionen arbeiten, jedoch ist der Typ eines Rückgabewertes fix. Somit muss ich einen Wert der diesem Typ entspricht auch im Fehlerfall zurückgeben. Dazu wird dann ein ungültiger Wert zurückgegeben. Das ist dann aber sehr speziell auf jede einzelne Funktion und deren Datentyp zugeschnitten. Ich wollte etwas in der Art "If @error" haben.

    Die typgerechte Rückgabe aus einer Funktion auch im Fehlerfall bleibt davon unberührt, aber ich habe eine allgemeingültige Fehlervariable, die sich dann auch schlüssiger lesen lässt.

    Die Fehlerfunktion wird mit dem Ergebnis einer Prüfung als Parameter aufgerufen. Zusätzlich wird ein (optionaler) Text für den Fehlerfall mitgegeben. Hier ist zu beachten, dass nur eine ungültige Prüfung (false) zum Fehler führt. Das Ergebnis der Prüfung wird von der Fehlerfunktion weitergeleitet, kann aber auch ignoriert werden (Bsp #2).