Wie ist euer Fehlersystem aufgebaut?



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



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

    Dem kann ich leider überhaupt nicht zustimmen, denn es widerspricht auch der Definition von robuster Software.

    Eine sinnvolle Fehlermeldung, welche eine eindeutige Fehlernummer beinhaltet, sowie eine verbesserte Möglichkeit der Fehlerreproduktion ist auf jeden Fall besser als die Software abstürzen zu lassen.

    Was verstehst du eigentlich unter einem Fehler ? Eine falsche Berechnung ? Ein unnormales Verhalten bei unnormalen Eingaben ? Ein unnormales Verhalten bei normalen Eingaben ? Ein Windows spezifischer Fehler ? Oder ein C++ typischer Fehler ?



  • Bitte ein Bit schrieb:

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

    Dem kann ich leider überhaupt nicht zustimmen, denn es widerspricht auch der Definition von robuster Software.

    Eine sinnvolle Fehlermeldung, welche eine eindeutige Fehlernummer beinhaltet, sowie eine verbesserte Möglichkeit der Fehlerreproduktion ist auf jeden Fall besser als die Software abstürzen zu lassen.

    Ne.
    Ein Programm nach einem Fehler weiterlaufen zu lassen, der so übel riecht, dass er eigentlich niemals hätte passieren sollen... DAS widerspricht der Definition von robuster Software 😉



  • @hustbaer
    Nein das meinte ich doch überhaupt nicht !!!

    Warum sollte ich bei einem schwerwiegenden Fehler das Program nicht beenden wenn es dem Benutzer schaden würde ?
    Warum sollte ich bei einem Program ala Word im Fall eines schwerwiegenden Fehler nicht vorher versuchen das Dokument abzuspeichern bevor ich das Programm terminiere ?
    Warum sollte eine Berechnungssoftware abstürzen, wenn der Benutzer die Software mit unsinnigen Daten füttert, anstatt das die Software eine Meldung der Form bringt: "Lieber Benutzer, deine Eingaben sind scheiße !" ?

    Ich denke das es von Fehlertyp und dem System abhängt welche Art von Fehlerbehandlung man machen kann. Der Begriff Fehler ist hierfür viel zu groß. Und beim Martin habe ich halt den Verdacht das er mit seiner Aussage Windows spezifische Fehler meinte und nicht Fehler im Allgemeinen. Bsp:

    HWND hWnd = CreateWindow(....);		// CreateWindow kann auch NULL zurückliefern
    ...
    PostMessage(hWnd, WM_NULL, 0, 0);
    

    Und vielleicht macht es hier Sinn das Programm abstürzen zu lassen. Aber macht es auch im folgenden Sinn ?

    void DoSomething(const CHAR* Name)
    {
      CHAR MyName[16];
      ...
      sprintf(MyName, Name);
    }
    ...
    DoSomething("Theodor von Gutenberg");
    

    Deswegen ziehe ich eher das Konzept des Exception Handling vor. Man kann dann im Fehlerfall immer noch entscheiden ob man das Program sauber (!!!) terminieren/herunterfahren will oder ob man mit dem Fehler (mit Hilfe einer Fehlerkorrektur) leben kann.


  • Mod

    Gerade der zweite Fall macht absolut Sinn einen Crash herbei zuführen...

    Woher weißt Du was die Anwednung auf dem Stack/Heap vernichtet hat und ob Deine "gut gemeinten Versuche" die Daten des Anwenders noch "zu retten" nicht genau im Gegenteil enden?

    Beides snd aus meine Sicht Fehler des Entwicklers und führen zum Crash.

    Das ein Fenster nicht angelegt werden kann, wird onst "soft" abgefangen und endet evtl. doch im Beenden des Programmes... aber eben weich und gesteuert mit sichern der Daten.

    Definiere Fehler im Allgemeinen:
    - Ein Programmiererfehler
    -- unzureichende Fehlerprüfung
    -- Bufferoverflow
    -- Falsche Parameter
    - Ein "harter" Fehler in der Ausführung
    -- Ein nicht zu erwartender I/O Fehler. DB Verbindung reißt ab etc.
    -- Kein Speicher mehr, keine GDI Handles.
    -- Eine DLL die installiert sein müsste ist nicht da oder hat eine falsche Version
    - Ein "weicher" Fehler bei der Ausführung
    -- Datei nicht gefunden (weil user sich vertippt hat)
    -- Datensatz nicht gefunden
    - Anwednungsfehler
    -- Benutzer gibt Schrott ein.

    Eigentlich führen die ersten beiden Kategorien bei mir sofort zum Programm-Abbruch und zu einem Dump und zum Reort über WER.



  • Es ist jetzt viel gesagt worden über alle möglichen Fehler und wie man als Programmentwickler damit umgehen soll. Es zeigen sich dabei auch unterschiedliche Programmierstile. Alle diese Programmierstile sind gerechtfertigt, wenn sie dem Ziel 'stabiles Programm' dienen.

    Grundsätzlich: Der Anwender hat damit nichts zu tun - er schreit wenn etwas nicht läuft wie er erwartet, fragt dann den Programmentwickler und fordert Abhilfe. Das ist sein gutes Recht, wenn er für die Software bezahlt hat oder für die Programmpflege weiter bezahlt.

    Also ist in jedem Fall der Programmentwickler gefragt. ER muss wissen, wie man Fehler möglichst vermeidet und wenn sie auftreten geeignete Methoden haben, wie man sie findet und schnell behebt. Das gehört zu jeder professionellen Programmierung notwendig dazu. Fehler können schliesslich Geld kosten! 😮 Ich denke z.B. an die Software für ein Walzwerk, wo Stahlbleche mit vorgeschriebener Dicke gefordert sind. Weicht diese Dicke vom Kundenauftrag ab, so ist die Produktion der Stahlbleche mit erheblichen Folgekosten im Eimer. In anderen Branchen gibt es ähnliches.

    Das Thema ist und bleibt in der Softwarentwicklung aktuell. Da kommt niemand drum herum!



  • Bitte ein Bit schrieb:

    Deswegen ziehe ich eher das Konzept des Exception Handling vor. Man kann dann im Fehlerfall immer noch entscheiden ob man das Program sauber (!!!) terminieren/herunterfahren will oder ob man mit dem Fehler (mit Hilfe einer Fehlerkorrektur) leben kann.

    Zu versuchen ein Programm sauber zu beenden, wenn man nicht sicher sein kann welche Invarianten alle schon verletzt sind, ist ein Glücksspiel. Und mMn. der ganz falsche Weg.
    Log-Eintrag schreiben, Crash-Dump schreiben, Prozess killen.


Anmelden zum Antworten