[Nim] Errorhandling

  • 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.