Jeden Fehler aufschreiben

  • Allgemein

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Jeden Fehler aufschreiben

    Hallo liebe Community

    ich wollt mal fragen ob ihr mir bei diesem problem helfen könnt.
    Und zwar habe ich ein Programm was 100% änderbar ist. Also alle Eigenschaften von der Form, Button etc. sind in textdokumenten gespeichert und werden beim laden abgerufen.
    Jetzt kommt es ab und zu mal vor das ich z.B. das Backgroundimage der Form nicht angebe (Den Pfad falsch/garnicht) und dann eine Fehler bekomm das halt die Datei unter dem Pfad nicht vorhanden ist, Ich kann in diesem fall das programm beenden, oder es eifnach weiter laufen lassen.


    Jetzt möchte ich das IMMER wenn ein Fehler auftritt egal was für einer, dieser einfach in der FehlerForm1 in eine Richtextbox geschrieben wird, sodass ich mir alle Fehler nochmal ankucken kann und das Programm ganznormal als wenn nciht wäre den Fehler ignoriert (der Benutzer nichts mitkriegt).

    Hoffe ich versteht das prinzip und könnt mir helfen

    MFG Eragon276
    Wenn der Benutzer nichts mitkriegen soll, schreibe den Fehler in eine Datei, nicht in eine RTB.
    Wenn das Programm ordentlich läuft und von außen beeinflusst werden kann, müsstest Du jede Routine in einen Try-Catch-Block einhüllen.
    Im Catch-Zweig befüllst Du Deine RTB oder den Error.Log und stellst ggf. einen korrekten Rückgabewert zur Verfügung.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich bin TryCatchens ja sehr kritisch gegenüber eingestellt. gugge AvoidTryCatch.
    Auch hier denke ich: Vlt läßt sich mit demselben Aufwand, auch "normal" (etwa per File.Exists()) überprüfen, ob ein String etwa einen gültigen Pfad enthält oder nicht.
    Aber meinetwegen: Die Daseinsberechtigung eines TryCatches besteht ja darin, dass für den Fehlerfall wirklich eine Option programmiert ist, wie das Programm weiterlaufen kann, und wenn deine Entscheidung so aussieht, dass Controls dann eben unvollständig generiert/konfiguriert werden, und ein Logging, dann ist das halt so eine Option.

    Ich glaub auch garnet, dass du nun "überall" TryCatchens machen mußt. Es wird ja eine Lade- und Verarbeite-Routine sein, und vlt. ists sogar nur eine einzige Stelle, wo der "Konfigurator" (oder wie du das programmiert hast) aufgerufen wird, und die gelesene Zeile an den übergeben wird.
    Spiele mit Deinem Programm ohne Trx-Catch und sieh nach, wo es knallt. Dort reparierst Du den Fehler und testest weiter.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Naja es ist auch so das ab und zu ein Fehler vor kommt der erst bei anderen Leuten auftritt beispielweise andere betriebsystem (XP,Vita,7) und halt wenn ein foto einfach fehlt dann ist der hintergrund halt weiß, es geht auch darum falls das programm mal abstürzen sollte, weil der ftp zu lange gebraucht hat oder ähnlichs das ich ein Fehlerdokument letztendlich als email erhalte und so der fheler mir beschrieben wird und ich ihn beheben kann..
    allgemeines Fehler-Logging macht man besser im Application_UnhandledException - Event, und danach Programm abbrechen.

    Weil für annere Fehler, als wenn mw. beim StartUp iein dummes Bild fehlt, hast du keine Option auf der Pfanne, wie das nunmehr instabile Prog weiterlaufen soll.

    Also IMO läuft Logging immer schön mit, bis zum ersten auftretenden wirklich unerwarteten Fehler. Und dann muß abgebrochen werden, und Support angefragt.