Wie ist euer Fehlersystem aufgebaut?



  • Hallo,
    mich würde mal interessieren wie euer Fehlersystem aufgebaut ist.
    Da ich heute erst gemerkt habe, wie schlecht meines eigentlich ist.
    Kunde schickt mir eine Email, eine MessageBox mit
    "VirtualProtect ist fehlgeschlagen! LastErrorCode: whatever" ist aufgetaucht.

    OK, ich kann zwar mit dem Error Code nachgucken was das Problem war,
    jedoch wenn ich 300 mal VirtualProtect aufrufe? Ich habe weder die Parameter, weiß weder welches VirtualProtect gemeint ist oder von wo die Funktion aufgerufen wurde.

    Ich will dem Benutzer aber auch nicht so eine Mittelung ala´
    VirtualProtect mit den Parametern .. .. .. .. in der Funktion CloneBrush ist fehlgeschlagen aufhalsen. Außerdem würde er dadurch viel zu viel von meinem Programm in Erfahrung bringen (Sicherheit).

    Wie macht ihr das? Man muss irgendwie den richtigen Mittelweg finden.



  • __FILE__, __LINE__



  • Das mit den Fehlern ist so alt wie die Programmierung. Es gibt da eine simple Regel unter Programmierern ´Du kannst nie wissen was der Benutzer alles falsch machen kann und musst darauf vorbereitet sein´. So etwas allein dem System zu überlassen ist und bleibt schlecht. Schlimmstenfalls stürzt das Programm ab oder macht ohne Absturz eine für den Benutzer unverständliche Meldung. Es ist und bleibt dein Ding, Fehlermöglichkeiten vorher zu planen, abzufangen und mit einer Korrekturmöglichkeit für den Benutzer einzurichten. Der grösste Teil eines jeden Programmes besteht immer in der saubereren Benutzerführung auch bei Benutzerfehlern. Anderenfalls hast du lästige emails oder Anrufe.

    Das alles gehört jetzt aber nicht unbedingt zur WinApi und wäre in der Rubrik ´Rund um die Programmierung´ vielleicht besser aufgehoben.



  • THEREAVER schrieb:

    Außerdem würde er dadurch viel zu viel von meinem Programm in Erfahrung bringen (Sicherheit).

    ROFL.
    Mhja, das wäre schon ganz viel schlimm.



  • Außerdem würde er dadurch viel zu viel von meinem Programm in Erfahrung bringen (Sicherheit).

    Security by Obscurity?



  • berniebutt es geht hier nicht um logische Fehler die man vorhersagen könnte.
    LINE und FILE hört sich schon mal gut an.

    Und wie machen es die anderen beiden?



  • THEREAVER schrieb:

    berniebutt es geht hier nicht um logische Fehler die man vorhersagen könnte.
    LINE und FILE hört sich schon mal gut an.

    Und wie machen es die anderen beiden?

    Welche anderen beiden?
    Klar, neben logischen Fehlern (Planung!) können jederzeit beim Programmlauf unerwartete weitere Fehler eintreten. Dafür gibt es Debug und weiteres. Wenn dich interessiert, wie ich es stets mache, siehe meine homepage http://berniebutt.npage.de Dort findest du einige Ausführungen zu einer Protokolldatei, die mir Debug weitestgehend erspart und auch für die Programmpflege nützlich sein kann.



  • Jo bernibutt,

    du hast schon von RAII gehört??
    Das schließen sollte doch dann auch automatisch im dtor erfolgen wenn diese
    noch offen ist,....

    Ansonsten ist so ein logwriter nett,.. greetz



  • Ich schiebe jetzt noch eine weitere Programmierweisheit aus Olims Zeiten rein: ´Only trivial programs are without bugs, but which program is trivial?´ Man kann das auf deutsch schwer so kurz und prägnant sagen. Man muss also mit Fehlern leben, sowohl aus der Programmplanung als auch woanders her. Wer bei unerwarteten Ereignissen oder Resultaten sehr lange suchen muss und nichts findet, hat oft schon verloren. Der Anwender nervt am Telefon: ´Das Programm läuft nicht, was soll ich mache? - am besten Sie kommen hierher!´



  • g++
    __PRETTY_FUNCTION__

    C++
    __FILE__
    __LINE__

    VC++
    __FUNCTION__
    __FUNCDNAME__
    __FUNCSIG__

    ... je nach Kompiler

    http://msdn.microsoft.com/en-us/library/b0084kay(v=VS.90).aspx .. da kannste oben umstellen welche MS VS 2005/08/10 du nutzt ...



  • THEREAVER schrieb:

    Und wie machen es die anderen beiden?

    Falls du damit mich und theta meinst...

    THEREAVER schrieb:

    Ich will dem Benutzer aber auch nicht so eine Mittelung ala´
    VirtualProtect mit den Parametern .. .. .. .. in der Funktion CloneBrush ist fehlgeschlagen aufhalsen. Außerdem würde er dadurch viel zu viel von meinem Programm in Erfahrung bringen (Sicherheit).

    Ich mache wenn möglich genau das. (Wobei "wenn möglich" heisst: wenn ich die Zeit dafür habe ordentliche Fehlerbehandlung zu schreiben). Ich sehe nämlich kein Problem darin, wenn der User diverse Funktionsnamen/Klassennamen etc. kennt.

    Idealerweise loggt man sowas in ein Logfile, und gibt es zusätzlich dem User aus.
    Genau so kann man Dinge in das Logfile schreiben, mit denen man noch umgehen kann (=wo man noch nicht eine Fehlermeldung ausgeben & abbrechen muss), die aber nicht auftreten sollten.


  • Mod

    Wenn der Fehler ein Fehler ist, der "nicht zum normalen Betrieb" gehört, wie z.B. Datei nicht gefunden oder andere Nachrichten, die aus der Benutzung der Software hervorgeht. Genau für solch "absonderlichen" Fehler sind möglichst genaue Informationen (mögen Sie auch füer den Anwender kyrptisch sein) genau das richtige.

    Anonsten: Lieber eine Software crashen lassen inkl. vernünftigen Crashdump, ale eine Fehlermeldung die weder dem Benutzer noch dem Entwickler hilft



  • Martin Richter schrieb:

    Wenn der Fehler ein Fehler ist, der "nicht zum normalen Betrieb" gehört, wie z.B. Datei nicht gefunden oder andere Nachrichten, die aus der Benutzung der Software hervorgeht. Genau für solch "absonderlichen" Fehler sind möglichst genaue Informationen (mögen Sie auch füer den Anwender kyrptisch sein) genau das richtige.

    Anonsten: Lieber eine Software crashen lassen inkl. vernünftigen Crashdump, ale eine Fehlermeldung die weder dem Benutzer noch dem Entwickler hilft

    Weitgehend einverstanden!

    Man muss also unterscheiden, welcher Art ein Fehler ist: vom System (z.B. zuwenig Speicher vorhanden, Datei nicht vorhanden, ...), vom Anwender (sollte das Programmdesign abfangen) oder vom Programmentwickler (bleibt seine Angelegenheit). Da Fehler nie ganz zu vermeiden sind, gehört deren jederzeitiges leichtes Aufsuchen schon ins Programm integriert, denke ich.

    Martin: eine Software crashen lassen und dann im Crashdump herumwühlen? Man weiss da doch nur, wo der Crash eingetreten ist und nicht unbedingt warum!

    Binsenweisheit: 'Fehler sind dazu da vermieden zu werden.' Und wenn sie doch auftreten, braucht man geeignete Methoden, sie schnell zu finden und zu beseitigen. Alle fremden Tools können im Fehlerfall nur helfen, aber niemals alles abdecken. Es interessiert mich auch, welche Vorschläge zu diesem immer aktuellen Thema kommen.



  • Martin: eine Software crashen lassen und dann im Crashdump herumwühlen? Man weiss da doch nur, wo der Crash eingetreten ist und nicht unbedingt warum!

    Naja, wenn das "wo" den Callstack aller laufenden Threads enthält, dann kann man damit oft schon viel anfangen.



  • Man muss also unterscheiden, welcher Art ein Fehler ist: vom System (z.B. zuwenig Speicher vorhanden, Datei nicht vorhanden, ...), vom Anwender (sollte das Programmdesign abfangen) oder vom Programmentwickler (bleibt seine Angelegenheit). Da Fehler nie ganz zu vermeiden sind, gehört deren jederzeitiges leichtes Aufsuchen schon ins Programm integriert, denke ich.

    Sorry, aber der letzte Satz...
    Programmierst du auch hin und wieder real, beruflich?



  • Da wir hier im WinAPI-Forum sind sollten wir folgende Funktionen nicht vergessen:
    GetLastError
    FormatMessage



  • hustbaer schrieb:

    Martin: eine Software crashen lassen und dann im
    Crashdump herumwühlen? Man weiss da doch nur, wo der Crash eingetreten ist und
    nicht unbedingt warum!

    Naja, wenn das "wo" den Callstack aller laufenden Threads enthält, dann kann man
    damit oft schon viel anfangen.

    Jo,. da haben mir Jochen und Martin n guten tip gegeben. MiniDumpWriterDump mit
    dem MiniDumpFullMemory Flag. So wie ich das gesehen und getestet habe hast Du
    quasi den kompletten zustand zum zeitpunkt der exception. Nettes gimmick. Und
    innerhalb eines __try{}__except{} blockes bleibt auch die app brav am laufen.

    Leider weiß ich immer noch net ob der exception handler auch bei
    R6016 anschlägt,.....

    greeetz



  • hustbaer schrieb:

    Man muss also unterscheiden, welcher Art ein Fehler ist: vom System (z.B. zuwenig Speicher vorhanden, Datei nicht vorhanden, ...), vom Anwender (sollte das Programmdesign abfangen) oder vom Programmentwickler (bleibt seine Angelegenheit). Da Fehler nie ganz zu vermeiden sind, gehört deren jederzeitiges leichtes Aufsuchen schon ins Programm integriert, denke ich.

    Sorry, aber der letzte Satz...
    Programmierst du auch hin und wieder real, beruflich?

    Irgendwie fällt mir ein, dass man wunderbar eine Feature von MS VS2010 bewerben könnte *gg* Aber ich hab's noch nicht genutzt 😮



  • Welches Feature?

    ----

    Ich habe das so aufgefasst, dass er meint ein Programm sollte so aufgebaut sein, dass man jeden Fehler schnell finden kann, nachdem er beim Kunden aufgetreten ist. Und das ist IMO Utopie. Es ist ein nobles Ziel, aber meist steht der Aufwand einfach nicht dafür, bzw. man hat einfach nicht die Zeit. Einen reproduzierbaren Fehler auf der Entwicklungsmaschine zu finden ist wieder ganz was anderes. Das sollte IMO wirklich (fast) immer schnell möglich sein, und das halte ich auch für ein halbwegs realistisches Ziel.

    Falls du dich auf diverse Debugging-Features beziehst. Und falls es das "Rückwärts-Debugging" sein sollte: das funktioniert nur mit .NET Programmen. (Ausprobiert hab ich's aber auch noch nicht)



  • Ja, IntelliTrace, wow als ich das zum ersten mal gesehen habe, aber stimmt gilt nur für .NET. Ist mir auch nur eingefallen, weil die Idee dieser Integration sehr nah kommt, obwohl IntelliTrace sau teuer ist (Nur in Ultimate verfügbar).


Log in to reply