Fehler kontrollen



  • hi,
    ich will euch mal fragen wie oft ihr fehler kontrollen benutzt:

    assert();
    signal();
    handler
    <setjmp.h>

    und gebtmal eure meinung zu den einzelen ab

    mfg
    Stelfer



  • Stelfer schrieb:

    assert();

    gelegentlich

    signal();
    handler
    <setjmp.h>

    nie (insbesondere letzteres gehört imho verboten

    Aber zur Suche nach logischen Fehlern hast du noch Lösungen wie TRACE() vergessen 😉



  • also findest du solch eine fehlerkontrolle nicht von bedeutung, du benutzt also lieber den debuger, oder wie soll ich das verstehen



  • Auf jeden Fall ist es besser, vor Ort zu sehen, was schiefgelaufen ist. Da ist ein kompletter Abbruch über assert() eher kontraproduktiv (und mit signal-Handling habe ich mich bislang wenig beschäftigt - aber das liegt wohl daran, daß das C++ Exception Handling eleganter ist ;)).



  • Signal-Handling habe ich überall wo ich möchte dass eine Unterbrechung von aussen nicht das Programm durch die Wand, sondern geordnet über ein im Handler zu setzendes Flag gesteuert zum Ende gelangt.

    Hat allerdings weniger was mit Fehlerbehandlung zu tun, wenn der Benutzer STRG-C in die Tastatur haut, kann das Programm ja (meistens) nichts dafür 😉



  • CStoll schrieb:

    Stelfer schrieb:

    assert();

    gelegentlich

    signal();
    handler
    <setjmp.h>

    nie (insbesondere letzteres gehört imho verboten

    Sieht bei mir gleich aus.

    assert ist gelegentlich schon praktisch, wenn man's hart und dreckig mag^^
    Aber meistens baue ich gar keine Prüfung auf invalide Eingaben bei Funktionen, die nur andere Programmier benutzen, oder so ein. Wer Müll reinkippt, kriegt Müll raus. :xmas1:

    EDIT: Debugger kommt sehr sehr sehr selten zum Einsatz, meistens finde ich den Fehler so oder mit Hilfe einiger "Status-printfs" oder ähnlichem.

    MfG

    GPC



  • GPC schrieb:

    ...
    Aber meistens baue ich gar keine Prüfung auf invalide Eingaben bei Funktionen, die nur andere Programmier benutzen, oder so ein. Wer Müll reinkippt, kriegt Müll raus....

    Klingt plausibel - bei mir fallen allerdings solche Prüfungen schon in der Designphase mit ab - wenn ich mir über Pre-(und Post-)conditions Gedanken mache, formuliere ich die sowieso schon in Code - dann mache ich mir gar nicht die Mühe, sie wieder rauszubauen. Und wenn mein Code nichts Falsches mehr machen kann, ist das Ergebnis garantiert richtig. 😉

    Allerdings hängt das auch mit der Komplexität der Aufgabenstellung zusammen (und die ist bei den Aufgaben, die man mir stellt, meist nicht besonders hoch).

    Gruß,

    Simon2.


Anmelden zum Antworten