Eure Erfahrungen mit Fehlerbehandlung

[Krishty]

Hi,

Ich wollte mich mal umhören, wie ihr Fehler behandelt und -- viel wichtiger -- warum ihr es so tut, wie ihr es tut.

Benutzt ihr Exceptions, Return-Codes oder behandelt ihr Fehler erst garnicht?

Wie geht ihr mit Fehlern um, sobald sie aufgetreten sind? Eine Message-Box an den User, ein Log-Eintrag, ein Hex-Dump mit E-Mail-Funktion? Eingeschränkt fortfahren? return -1;? Oder einfach die PDBs mitausliefern? :)

Hintergrund ist, dass ich meine programm- und entwicklungsinterne Fehlerbehandlung so ziemlich perfektioniert habe und nun vor der zweitgenannten Frage stehe, wie ich den Fehler dem User klarmache. Würde mich über ein paar bewährte Best-Practices und verschriene No-Gos freuen.

Gruß, Ky

[Seraph]

Wir nutzen primaer Exceptions und sollte mal eine gar nicht behandelt werden, wird sie gaaaaaanz weit aussen/oben abgefangen, ein Fenster generiert mit den entsprechenden Infos (Exception, Callstack, etc.) und der Moeglichkeit den Inhalt auf Knopfdruck per Email zu versenden. Fuer spaeter werden wir die Infos fuer den User wahrscheinlich etwas einschraenken und dafuer noch Text hinzufuegen, warum es wichtig waere es an uns zu versenden und ihm natuerlich die Moeglichkeit zu geben, zu beschreiben, was er gerade gemacht hat. Wichtig ist denke ich, ihm die Wahl zu lassen, was er machen moechte.

[Psycho]

Best-Practice: Nur fehlerfreie Programme ausliefern.

Hab bisher auch nur mal drüber nachgedacht und ich würd dem User ne MessageBox anzeigen von wegen "Uhhh, es tut mir soo leid." mit großem OK-Button und kleinen Report-Button.
Ich weiß gar nicht, ob es Standard-Dumps gibt. Mir wäre aber hauptsächlich EIP und Callstack wichtig. Die PDBs von genau der Version des Users hab ich dann (hoffentlich) irgendwo, um zu analysieren woran es hakt.

Wie ich Fehler im Programm behandel? Für mich selber benutz ich Exceptions für kritische Fehler, aber für viele fremde Funktionen muss man ja mit Return-Values arbeiten. Je nachdem, ob der Fehler kritisch ist, gehts anschließend weiter, sonst nicht. Was will man machen!?

Off-Topic: Ganz schöner Quatsch, dass es zur Mode wird, für jeden Tab einen eigenen Prozess zu bauen. Find ich jedenfalls so intuitiv. Jaja ich weiß, abstürzende Plugins usw...tüdeldu...aber ey, Prozesse! Was meint ihr?

[kimmi]

Meist wenige globale Try-Catch-Blöcke und im Gewühl mehr Rückgabe-Werte, da ich unter anderem mit älteren C-API's arbeiten muss. Kritische Fehler sorgen für einen Neustart der Anwendung bzw. Abflug mit Asserts. Weniger kritische fehler protokolliere ich, damit man im Log hoffentlich nachvollziehen kann, wo der Fehler aufgetreten ist und wann einem dieser Fehler dann die Applikation kaputt gemacht hat. Message-Boxen benutze ich eher weniger.

Gruß Kimmi

[Krishty]

Wichtig ist denke ich, ihm die Wahl zu lassen, was er machen moechte.

Aber Call-Stacks, Exceptions überfordern User – vor allem, wenn sie unerwartet kommen. Und wenn dann noch Fenster zur Texteingabe daneben sind und mehrere Buttons, verfallen die meisten in Panik und drücken X. Ich habe jedenfalls mal gelesen, dass eine Wahl in solchen Fällen das Letzte ist, was ein User will oder braucht (und erst recht der Entwickler).
Seit ich gestern im Zug an einer kaputten Tür saß und beobachtete, wie >95 % der Leute trotz Quadratmetergroßer Warnaufkleber getunnelblickt auf den Knopf gedrückt haben zweifle ich daran, dass das auf was anderes hinausläuft als X zu drücken und die Anwendung neu zu starten. Dann wieder X und neustarten. X und neustarten. Dann jemanden anrufen, der sich damit auskennt …
… gibt es irgendwo Statistiken von Programmen, die das so machen, wie viel Feedback da tatsächlich zurück kommt? Z.B. vom Windows-Error-Reporting, das (vielleicht nicht zufällig nur) bis Vista gefragt hat, ob man Fehlerinformationen übermitteln möchte?

Best-Practice: Nur fehlerfreie Programme ausliefern.

Ist ein interessanter Punkt … ich habe schon öfter darüber nachgedacht, ob man nicht garantieren könnte, dass die Anwendung, sobald sie auf der Platte ist und solange niemand daran rumgefummelt hat, fehlerfrei läuft. Das setzte dann aber auch eine Installation voraus, die die Laufzeitumgebung darauf testen würde, ob ausreichende Hardware verbaut sei usw. Wenn die Anwendung doch mal abstürzen würde, dann nur, weil jemand an den Dateien rumgefummelt hat (ein Modder [um mal bei der Spieleentwicklung zu bleiben]) und dann könnte man genug Kenntnisse voraussetzen, um dem Fehler auch mit einem guten alten Log auf die Schliche kommen zu können.
… die Sache ist nur, dass ich nicht ganz soviel Vertrauen in die Qualität meiner Anwendung habe … nicht beim gleichzeitigen Support des ausklingenden x86 und anbrechenden x64, und erst recht nicht bei sich wechselnden Hardware-Konfigurationen, von denen die Anwendung überhaupt keine Kenntnis haben kann, bis es zu spät ist.

[…] bzw. Abflug mit Asserts.

Wow. Sowas lieferst du aus?
Aber das mit dem Log interessiert mich, weil ich so einen auch schon habe … kommen die User damit zurecht? Dann würde ich beim Abflug nämlich schlicht und einfach die Log-Datei öffnen und dem User vorlegen.

Achja – bin positiv überrascht, dass Exceptions schon so etabliert sind …

Off-Topic: Ganz schöner Quatsch, dass es zur Mode wird, für jeden Tab einen eigenen Prozess zu bauen. Find ich jedenfalls so intuitiv. Jaja ich weiß, abstürzende Plugins usw...tüdeldu...aber ey, Prozesse! Was meint ihr?

30 Prozesse verhaken sich weniger wahrscheinlich gegenseitig als 30 Threads. Man verschiebt einen gewissen Teil der Verantwortung (z.B. die Arbeitszeitzuteilung und die Speicherfragmentierung) zum Betriebssystem, in dem 20 Jahre Erfahrung stecken, statt das selber zu programmieren. Und zu guter Letzt erzeugt z.B. Chrome nicht für jedes Tab einen Prozess, sondern für jede Tab-Gruppe (also für alle Tabs derselben Domain, in denen man gerade surft). Wo sollen die Nachteile sein?

[Schrompf]

Wir werfen jetzt primär mit Exceptions. Nicht unbedingt, weil es so toller Stil ist, sondern eher, weil dadurch die Programme so viel kürzer und einfacher werden. Erfordert natürlich auch eine andere Disziplin im Umgang mit Resourcen... aber mal ehrlich: wie oft löscht man in modernem C++ denn tatsächlich noch Resourcen von Hand? Einmal pro Monat? Bestenfalls.

Return Codes sind für alle Funktionen, bei denen ein Scheitern ein im normalen Ablauf zu erwartendes Ergebnis ist. Z.B. so Sachen wie "gib mir das XYZ zu diesem Namen" - da kommt halt ein Null-Pointer oder eine Referenz auf ein als invalid markiertes Objekt zurück. Das finde ich einfach bequemer, als einen TryCatch-Block drumrum zu bauen, und ein bisschen Performance spart es auch.

[Lord Delvin]

Best-Practice: Nur fehlerfreie Programme ausliefern.

Interessant. Dachte es gibt noch keine Formale Verifikation von größeren (C++) Programmen:D

Off-Topic: Ganz schöner Quatsch, dass es zur Mode wird, für jeden Tab einen eigenen Prozess zu bauen. Find ich jedenfalls so intuitiv. Jaja ich weiß, abstürzende Plugins usw...tüdeldu...aber ey, Prozesse! Was meint ihr?

30 Prozesse verhaken sich weniger wahrscheinlich gegenseitig als 30 Threads. Man verschiebt einen gewissen Teil der Verantwortung (z.B. die Arbeitszeitzuteilung und die Speicherfragmentierung) zum Betriebssystem, in dem 20 Jahre Erfahrung stecken, statt das selber zu programmieren. Und zu guter Letzt erzeugt z.B. Chrome nicht für jedes Tab einen Prozess, sondern für jede Tab-Gruppe (also für alle Tabs derselben Domain, in denen man gerade surft). Wo sollen die Nachteile sein?

Deadlocks hängen nur vom Kontrollfluss ab und nicht von der Implementierung des Kontrollflusses; d.h. es ist relativ egal was du für Parallelisierungstechniken verwendest, solange es keine coroutines sind, d.h. *threads* die durch explizite thread switch Anweisungen gescheduled werden, weil es keinen OS Scheduler gibt, was dazu führt, dass gleichzeitig immer nur einer arbeitet.
Das mit den Abstürzenden Plugins finde ich komisch, weil ich das Problem damals so gelöst hab, dass jedes plugin in seiner eigenen vm gelaufen ist. Ist zwar nicht schnell, aber ziemlich sicher. Und kein Mensch braucht schnelle Plugins. Wenns wirklich gut ist, dann kann mans auch in ordentlicher Form in der nächsten Version integrieren und optional machen.

[kimmi]

Wow. Sowas lieferst du aus?

Wenn es sich um eine Dev-Library handelt? Ja, als Dokumentation von Contracts. Wenn es sich um eine Anwendung für einene Anwender handelt eher nicht.

Mit den Logs kommen User in sofern zurecht, als das man ihnen diese ja in einem Fenster zur Laufzeit anzeigen kann. Dann sehen sie, was sie wann falsch gemacht haben ( beispielsweise Laden des Modelles war fehlerhaft wegen xxx ). Das hängt halt immer von dne Kunden ab. Im Job arbeite ich an einem Framework mit, da sind die Kunden in der Regel ebenfalls Entwickler. Und vielen Entwicklern liegen Logs mehr als Messageboxes.
Wenn die Kunden aber Endanwender sind, wollen die nach Möglichkeit ein nicht abstürzendes Programm. Da versuche ich dann, diese auch zu vermeiden.

Gruß Kimmi

[Krishty]

Wenn es sich um eine Dev-Library handelt? Ja, als Dokumentation von Contracts. Wenn es sich um eine Anwendung für einene Anwender handelt eher nicht.

Okay, dachte schon :)

Das hängt halt immer von dne Kunden ab. Im Job arbeite ich an einem Framework mit, da sind die Kunden in der Regel ebenfalls Entwickler. Und vielen Entwicklern liegen Logs mehr als Messageboxes.

Stimmt.

Deadlocks hängen nur vom Kontrollfluss ab und nicht von der Implementierung des Kontrollflusses; d.h. es ist relativ egal was du für Parallelisierungstechniken verwendest, solange [...]

Okay, ich meinte: Arbeitet man mit Threads, gibt es oft globale Ressourcen, die mit abstürzen wenn ein Thread kracht. Die gibt es bei Prozessen zwar genauso, aber die Wahrscheinlichkeit dass das ganze UI nicht mehr reagiert weil ein Tab hängt, ist wesentlich geringer.

Das mit den Abstürzenden Plugins finde ich komisch, weil ich das Problem damals so gelöst hab, dass jedes plugin in seiner eigenen vm gelaufen ist. Ist zwar nicht schnell, aber ziemlich sicher. Und kein Mensch braucht schnelle Plugins. Wenns wirklich gut ist, dann kann mans auch in ordentlicher Form in der nächsten Version integrieren und optional machen.

Im Zusammenhang mit Chrome habe ich auch was von Sandboxes gehört ... ob es jetzt nur für Java-Anwendungen war oder ob die Plugins drin liefen, weiß ich aber nicht mehr.

Return Codes sind für alle Funktionen, bei denen ein Scheitern ein im normalen Ablauf zu erwartendes Ergebnis ist. Z.B. so Sachen wie "gib mir das XYZ zu diesem Namen" - da kommt halt ein Null-Pointer oder eine Referenz auf ein als invalid markiertes Objekt zurück. Das finde ich einfach bequemer, als einen TryCatch-Block drumrum zu bauen, und ein bisschen Performance spart es auch.

Ich würde die Namen garnicht erst invalid werden lassen - und das mit der Performance hängt davon ab, wie oft der Name ungültig ist. Als etwas, wo man ein Fehlschlagen erwartet, würde ich eher User-Eingaben bezeichnen.

[Alexander Kornrumpf]

zweifle ich daran, dass das auf was anderes hinausläuft als X zu drücken und die Anwendung neu zu starten. Dann wieder X und neustarten. X und neustarten.

Also ein Stichwort was sich mir gerade ins Gedächnis ruft ist "fail early". Auch wenn damit vielleicht eigentlich was anderes gemeint war, passt es glaube ich ganz gut zu deinem Argument. Wenn der Tunnelblick-Anwender immer 30 min am Stück mit der Anwendung arbeiten kann bevor sie abstürzt, dann wird er zwar fluchen, aber genau das tun. Er wird dieses Verhalten nicht als Fehlfunktion erkennen, weil wir seit Win95 gewöhnt sind, dass sich "Computer eben so verhalten". Stürzt die Anwendung dagegen direkt nach dem Start ab und der Anwender kann sie folglich gar nicht benutzen, wird er zu der Erkenntnis kommen, es sei etwas kaputt.

Etwas zu Exceptions und RAII was mich schon immer gewundert hat:
Leider fehlt in meinem Studiengang eine Betriebssystemvorlesung. Ich gehe jedoch davon aus, dass Speicher den ein Prozess mal angefordert hat, dem OS auf jeden Fall wieder zur Verfügung steht, wenn der Prozess aus welchem Grund auch immer endet. (Auf die ein oder andere Weise muss virtueller Speicher zumindest indirekt diese Konsequenz haben, nehme ich an, schlimmstenfalls liegen die Daten von dem toten Prozess dann halt irgendwo auf der Platte in einer Page die nie wieder jemand aufruft). Diese ganze Obsession von C++ Programmierern bezüglich korrekter Speicherfreigabe im Falle einer Exception macht also eigentlich nur Sinn, wenn die Exception irgendwo behandelt wird und die Anwendung weiterläuft.

Irgendwie werde ich dabei das Gefühl nicht los, dass man beim Design des ganzen Exception-Mechanismus weder moderne Desktop-Rechner, noch entsprechende Endanwender-Software im Hinterkopf hatte. Im genannten Szenario wird es nur ganz selten mal vorkommen, dass wirklich mal was schief geht (z.B. dass new fehlschlägt) und wenn doch, dann gibt es vermutlich auch nichts was der unbedarfte Nutzer tun könnte um die Situation noch irgendwie zu retten, außer halt eine MessageBox wegzuklicken und neu anzufangen. Kurz gesagt, ich glaube dass die Idee man könne einen Fehler irgendwie "behandeln" in vielen Fällen Selbstbetrug ist.

(Das oben gesagte gilt natürlich alles nicht wenn Exceptions für Ausnahmebedingungen verwendet werden, die in dem Sinne keine Fehler sind, insbesondere wenn der Designidee entsprechend jemand "weiter außen" weiß was zu tun ist. Allerdings erfährt der Nutzer davon entweder gar nicht (das Problem wurde ja gelöst) oder die Benachrichtigung an den Benutzer muss für jeden Fall neu designt werden "ich habe Problem xy festgestellt, bei dem du mir helfen kannst indem du z tust/entscheidest".)

[Lord Delvin]

Leider fehlt in meinem Studiengang eine Betriebssystemvorlesung. Ich gehe jedoch davon aus, dass Speicher den ein Prozess mal angefordert hat, dem OS auf jeden Fall wieder zur Verfügung steht, wenn der Prozess aus welchem Grund auch immer endet. (Auf die ein oder andere Weise muss virtueller Speicher zumindest indirekt diese Konsequenz haben, nehme ich an, schlimmstenfalls liegen die Daten von dem toten Prozess dann halt irgendwo auf der Platte in einer Page die nie wieder jemand aufruft). Diese ganze Obsession von C++ Programmierern bezüglich korrekter Speicherfreigabe im Falle einer Exception macht also eigentlich nur Sinn, wenn die Exception irgendwo behandelt wird und die Anwendung weiterläuft.

Das ist schon so, der Punkt ist aber, dass man alle Ressourcen freigeben will. D.h. z.B. man will alle Logs in einem sinnvollen Zustand hinterlassen und nicht leer, weil sie nicht ausm Speicher auf die Platte geschrieben wurden, oder schlimmeres.

[Krishty]

Genau, flushen aller Puffer z.B.. Oder kappen aller Verbindungen (Flash-Uploads laufen sonst weiter, wenn der Browser abstürzt).

[Alexander Kornrumpf]

Genau, flushen aller Puffer z.B.. Oder kappen aller Verbindungen (Flash-Uploads laufen sonst weiter, wenn der Browser abstürzt).

Dass es andere Ressourcen als Speicher gibt war mir schon bewusst. Aber die "Literatur" über RAII ist da nicht immer eindeutig, bzw. kommt aus einer Zeit in der Speicher wirklich eine kritische Ressource war.

[Krishty]

Naja, selbst, wenn der Speicher am Programmende freigegeben wird - es treten auch vorher schon Exceptions auf und falls sie gefangen werden und man anders weitermacht, will man kein Speicherleck. Beispiel Texturklasse:

Eigentlich prädestiniert für Exceptions, weil bei der Auslieferung alle Dateien da sind (Fehler treten nie auf), und gleichzeitig von der Speicherallokation über die Dekodierung der Bilddateien bis zum Schaufeln auf die GPU alles schief gehen könnte.

Nun gibt es aber Modder, die schonmal die ganze Umgebung basteln und nicht eine einzige ihrer Texturen definieren, sondern die Defaults lassen. (Jede zweite CS-Source-Kiddie-Map.) Wenn du da nicht hinter dir aufräumst, hast du 200 Texturen als Speicherleichen rumliegen, das ist irgendwie nicht gut.

Darum sollte man immer freigeben, was man allokiert hat. Das OS macht das nur in letzter Instanz. Außerdem werden Destruktoren ja nicht bloß für Exceptions benutzt, wenn man es richtig macht, kann man als Programmierer zwischen gutem und schlechtem Beenden der Anwendung garnicht mehr unterscheiden. Das meint Schrompf auch damit, dass der Code kürzer und einfacher wird: Man schreibt, als würden Fehler nie auftreten. Wenn sie es aber doch tun, passiert nichts Schlimmes mehr. Einfach perfekt.

Zu fail early kommt heute mittag noch was.

[Schrompf]

[edit] Ich beziehe mich auf Alexanders Argument, dass der Gedanke an lokale Resourcen verschwendet wäre, wenn das Programm damit sowieso endet.

Ne, sorry, aber das ist Unsinn. Exceptions werden *immer* dann geworfen, wenn der Programmierer der Meinung ist, dass äußerer Code trotzdem irgendwie weitermachen kann. Als Debug-Werkzeug ist eine Assertion deutlich nützlicher - die sagt nämlich im Gegensatz zu Exceptions tatsächlich aus, dass da was faul ist, das eigentlich hätte richtig sein sollen, und man kann live mit dem Debugger reinschauen.

Exceptions waren für mich immer ein Signal, dass aussagt: "Ok, ich kann hier nicht mehr weitermachen, aber ihr da draußen könnt". Ein "Oh mein Gott, dazu hätte es nie kommen dürfen." ist dagegen keine Exception - und in dem Fall kann man dann auch die Resourcen oder sonstwen ignorieren. Das OS gibt sowieso alles frei, wenn der Prozess endet.

Dass mit RAII-Werkzeugen wie dem boost::scoped_ptr und Artverwandten außerdem auch der Code deutlich kürzer wird, ist nur ein angenehmer Nebeneffekt.

[Alexander Kornrumpf]

Krishty: Alles klar und richtig. Natürlich sollte man das System in einem möglichst gesunden Zustand zurück lassen und an Daten retten was zu retten ist. Das würde ich nie bestreiten. Worum es mir geht, ist dass man vermutlich auch nicht viel mehr tun kann als das. Wenn einem nichts anderes zur Behandlung des Fehlers mehr einfällt, als eine Dokumentation seines Auftretens ist das meinem Verständnis nach keine echte Behandlung, es löst ja das Problem nicht.

Wenn die Anwendung trotzdem weiter laufen kann, war das Problem ja per Definition nicht ganz so schlimm, wozu dann die Aufregung.

Muss die Anwendung dagegen beendet werden ist ein kontrollierter "Nothalt" aus Sicht des Benutzers kaum von einem Absturz zu unterscheiden. In beiden Fällen klickt er X und startet neu, wie du schon so richtig festgestellt hast. Was soll er auch anderes tun?

Thomas:
Aber hier geht es doch um den "Oh mein Gott, dazu hätte es nie kommen dürfen." Fall. Ich habe doch in meinem Beitrag an zwei Stellen geschrieben dass ich mich nicht auf die Situation beziehe, in dem jemamd weiter außen das Problem lösen kann. Überspitzt formuliert: Weiter außen als der Mensch vor dem Rechner geht es nicht. Wenn selbst der nichts mehr tun kann, ist die Sache eben in die Hose gegangen. Was dann bleibt ist vielleicht Schadensbegrenzung aber Fehlerbehandlung wäre für mich ein Euphemismus.

[Krishty]

Wenn die Anwendung trotzdem weiter laufen kann, war das Problem ja per Definition nicht ganz so schlimm, wozu dann die Aufregung.

Dafür sind dann die catch-Blöcke da. Die entscheiden, ob ein Fehler recoverable ist oder ob man die Ausnahme weiterreicht. Für den Benutzer ist der Unterschied nicht sichtbar, aber dem Entwickler spart es viel weil der Code einfacher wird und sich alles im Fall einer Exception automatisch richtig verhält, nämlich genau so, als würde der Code normal beendet werden.

[Schrompf]

Ok, da reden wir vom gleichen Fall: wenn das Programm nicht weiterlaufen kann, dann sind die Resourcen auch Schnuppe. Da kann einem RAII auch gepflegt den Buckel runterrutschen. Für den Fall würde ich dann einen globalen Ärger-Handler beim System anmelden und das Log vollpumpen. Funktioniert bei uns bisher ziemlich gut, auch wenn wir doch ziemliche Probleme haben, selbst die langjährigen Teammitglieder daran zu gewöhnen, dass sie das verdammte Log mit ihren Fehlerberichten mitschicken. So ein aufpoppendes Fenster mit EMail-Option wäre da ne tolle Sache.

[Alexander Kornrumpf]

Wenn die Anwendung trotzdem weiter laufen kann, war das Problem ja per Definition nicht ganz so schlimm, wozu dann die Aufregung.

Dafür sind dann die catch-Blöcke da. Die entscheiden, ob ein Fehler recoverable ist oder ob man die Ausnahme weiterreicht. Für den Benutzer ist der Unterschied nicht sichtbar, aber dem Entwickler spart es viel weil der Code einfacher wird und sich alles im Fall einer Exception automatisch richtig verhält, nämlich genau so, als würde der Code normal beendet werden.

Aber dafür hast du diesen Thread doch nicht gestartet, oder?

[kimmi]

Das ist so eine Sache mit dem richtigen Verhalten. ich habe mal an einer Modellierungssoftware für Simulationen mitgearbeitet und dort hatten wir ein ähnliches Problem zu lösen: wie geht man mit Fehlern um, die die Datenbasis ( die Out-of-Core gehalten wurde und mehrere Gigs umfassen konnte bzw. kann ) eventuell in einen nicht definierten Zustand bringen kann. Wir haben uns dann für die Abflug-Variante entschieden, damit man nicht irgendwann durch Datenirritationen verfälschte Berechnungsergebnisse erhält, die dann zu falschen Konstruktionen führen.
Allerdings haben wir das mit Error-Eskalations-Levels beschrieben ( Fatal, normaler Error, Warnung, Info und Debuginfo ). Fatale Fehler weisen auf wirkliche Bugs hin, Errors und Warnungen weisen auf Anwendungsfehler hin. Hat man beispielsweise vor, eine Schraube zu modellieren und die Kontaktfläche zwischen Schraube und Gewinde vergessen, ist das kein Programmfehler. Ist der Kontakt-Algorithmus buggy, hilft auch keine Nutzeraktion mehr. Das musst man nun konsequent im Code vorsehen, damit das korrekt umgesetzt wird. Und natürlich schlug dann die Faulheit zu und Entwickler fingen an, Errors wie "Var i ist gleich 0" als Benutzerfehler zu definieren, was zu gewissen Irritationen von Seiten der Anwender führte :). Gegen sowas hilft dann aber recht zuverlässig Code-Lesungen.

Gruß Kimmi

[Krishty]

Aber dafür hast du diesen Thread doch nicht gestartet, oder?

[…] nun vor der zweitgenannten Frage stehe, wie ich den Fehler dem User klarmache.

Mit der ersten Frage wollte ich nur ein bisschen Orientierung, wie die Fehlerbehandlungsmechanismen so verteilt sind … wenn ich verschiedene Webforen überfliege, werden da zu zwei Dritteln Return-Codes behandelt. Es hätte ja tatsächlich sein können, dass hier jemand sagt: Scheiß auf Return Codes oder Exceptions, wir liefern alles komplett ohne aus und es läuft. Dem galt mein Interesse.

Die Frage, in der ich wirklich Hilfe brauche, ist die, wie ich dem User den Fehler klarmache.

@kimmi: Das klingt wirklich gut. Wie wurden die einzelnen Fehlerarten mitgeteilt? „Abflug“ heißt, tatsächlich ohne Meldung geschlossen?

[kimmi]

Abflug heißt: Applikation stürzt ab. Mit Glück kriegt man noch einen Crashdump oder einen Callstack. So in der Form versuche ich das seitdem durchzuziehen. Klapt eigentlich ganz gut. Logs sind durch so etwas dann wirklichz nützlich, um den Punkt, an dem der Fehler aufgetreten ist ( Eingabefehler vom Benutzer oder wirklicher Programmfehler ) bis zu dem Punkt, wo das Programm gegebenenfalls abgeflogen ist, nachvollziehen zu können. Das ist halt viel aussagekräftiger als eine Messagebox mit "Ich bin dann mal weg!", auch für technisch nicht so versierte Benutzer.

Gruß Kimmi

[Chromanoid]

Ich denke es kommt auch ziemlich darauf an, wie eng man mit Kunden Kontakt hat, wie wichtig die fehlerfreiheit ist und um was für Produkte es sich handelt. Je nach dem muss man dann abwägen wieviel zeit man in die Fehlerbehandlung investieren möchte. Bei Software mit wenigen wichtigen Kunden, deren Kaufentscheidung besonders mit dem Support zu tun hat, sollte man natürlich den höchst möglichen Komfort für die Kunden und die reagierenden Entwickler/Supporter bieten.
Bei kleinen "unterbezahlten" Projekten, die im Rahmen von Werkverträgen ohne besondere Ansprüche auf gute Fehlerbehandlung stattfinden, kann man auch auf eine besonders benutzerfreundliche Fehlerbehandlung verzichten. Der Benutzer muss dann eben eine Logdatei aus einem Verzeichnis raussuchen und dem Entwickler selbst per Email zu schicken, um Hilfe zu bekommen. Fehlerfreie Software gibt es schließlich nicht wirklich und wenn nicht extra dafür bezahlt wird sollte man sich dafür auch nicht besonders viel Mühe geben (es sei denn man erhofft sich größere Folgeaufträge und ist bereit dafür auch kostenlos an der Fehlerbehandlung zu arbeiten). Ggf. kann man ja auch eine kleine Bibliothek dafür wiederbenutzen... (die entwickelt sich natürlich auch nicht einfach so ohne Kosten...).

Was jetzt genau höchsten Komfort bei Fehlerbehandlung bedeutet ist ja eigentlich schon gesagt worden... Man könnte das ganze vielleicht so nochmal aufdröseln:
Technische Fehler, die vom Benutzer eh nicht behoben/verstanden werden können sollten sich auch so darstellen und sich nur bei einem Knopfdruck auf "Technische Details" o.Ä. in voller Schönheit offenbaren. Eine Email-/Druckfunktion mit Screenshotmöglichkeit für solche Fehler mit entsprechenden Daten wie z.B. Stacktrace o.Ä. ist sicherlich sinnvoll.
Fehler die vom Benutzer behoben werden können, sollten immer mit entsprechenden Anweisungen gemeldet werden. Als Beispiel wäre da eine nicht beschreibbare Datei zu nennen, die von einem anderen Programm verwendet wird.
Auf jeden Fall sollten Fehler auch immer in eine Log-Datei geschrieben werden, die zur Not vom Supporter angefordert werden kann. Wichtig ist bei komfortabler Fehlerbehandlung natürlich auch die Möglichkeit nach einem Absturz die "letzte Sitzung" wieder herzustellen.

Bei Java ist die Fehlerbehandlung meiner Meinung nach ziemlich gut gelungen und schön in das Gesamtkonzept integriert. Man hat als Programmierer überall einen Logger zur Verfügung (mit mehreren Log-Levels), der bei Exceptions einen Stacktrace ausgeben kann und alles in beliebige Loghandler (z.b. email handler, text datei handler, konsolenhandler, dialogbox handler und html datei handler) schreibt. Die Handler muss man zwar teilweise selbst programmieren, aber das geht schnell von der Hand und man kann sie überall wiederverwenden... http://java.sun.com/j2se/1.4.2/docs/api ... ndler.html Da es sich dabei nicht unbedingt um ein neues Konzept handelt sollte es das ganze natürlich auch in anderen Sprachen geben... Für die Leute die Stacktraces nicht benutzen, so sieht ein Java-Stacktrace aus :):

Code: Alles auswählen

java.lang.ArrayIndexOutOfBoundsException: 3
  at example.common.TestTry.execute(Testtry.java:17)
  at example.common.TestTry.main(Testtry.java:11)

Sehr praktisch, da Fehlerart und zeile im Code usw. angegeben wird. Gibts natürlich auch in C# und anderen "dynamischen" Sprachen :).

[zwergmulch]

Was ich bei Java aber manchmal sch****(*) finde, sind die "Checked Exceptions". Die sorgen dann meistens für folgenden Code, wenn man in eine Datei schreiben will:

Code: Alles auswählen

BufferedWriter writer = null;
try{
     writer = new BufferedWriter (new FileWriter (file));
     // text schreiben...
} catch (Exception ex){
     ex.printStackTrace ();
} finally{
    if (writer != null){
        try{
            writer.close ();
        } catch (Exception ex){}
    }
}

Über den Sinn dessen kann man nun streiten... :twisted:


Edit: Komisch, egal wie viele Leerzeichen ich einfüge - am Ende sieht man davon nichts (in den Code-Tags).
Und Tabs gehen auch nicht - sollte man evt. mit (wie hieß das nochmal: xml-space oder so) verändern.

[Chromanoid]

mach mal [ code = java ]

mmh naja nen finally ist schon sinnvoll und den rest kannst du ja einfach von der methode werfen lassen...

[zwergmulch]

@code = java : Oh, schon besser... ;-) Danke.

Wenn der Benutzer nun an der Konsole (wahrscheinlich eher nicht) den Stacktrace sieht und das Programm abstürzt, hilft ihm das auch nicht so.
Catch kann man zwar weglassen, aber meistens führt das dazu das der Fehler "verschluckt" wird -
auch nicht das beste. So kann man wenigstens mit System.setErr () das in eine Log-Datei umleiten. Aber mir ging es um den allgemeinen Sinn von Checked Exceptions.

[Chromanoid]

naja ich finde checked exceptions eigentlich ziemlich gut, da wird man gezwungen sich mit den möglichen fehlern auseinander zu setzen. und wie gesagt, man kann die meisten fehler ja sonst euch einfach hochreichen und an einer übergeordneten stelle abfangen und dann gleich mehrere auf einen schlag.

[Krishty]

:shock: Das ist ja wirklich grausam … wird man zu Checked Exceptions gezwungen, wenn man bestimmte Objekte benutzt (in diesem Fall BufferedWriter) oder kann man sich aussuchen, die zu benutzen?

Ist das, um zu garantieren, dass Ressourcen freigegeben werden, falls Ausnahmen auftauchen? Wenn ja – ohne mal wieder auf Java fluchen zu wollen – in C++ wären das fünf saubere Zeilen … dann zwar ohne schicken Stack-Trace, aber … óÔ

Mein Java-Kurs dauerte nur ein Semester, darum sorry, falls die Fragen dumm sind …

[Seraph]

Wichtig ist denke ich, ihm die Wahl zu lassen, was er machen moechte.

Aber Call-Stacks, Exceptions überfordern User – vor allem, wenn sie unerwartet kommen. Und wenn dann noch Fenster zur Texteingabe daneben sind und mehrere Buttons, verfallen die meisten in Panik und drücken X. Ich habe jedenfalls mal gelesen, dass eine Wahl in solchen Fällen das Letzte ist, was ein User will oder braucht (und erst recht der Entwickler).

Wie ich schon schrieb, werden die sichtbaren Infos spaeter fuer den User eingeschraenkt. Solange es aber eine reine Entwicklungsversion ist, wird weiterhin ein Form mit allen verfuegbaren Infos ausgegeben. Und dem User die Wahl zu lassen bezog sich darauf, ob er es abschickt oder nicht. Weil ich habe auch schon Applikationen erlebt, die einfach ohne Nachfrage versuchen einen Error-Report zu versenden. Sprich der User hat die Moeglichkeit zwischen 'Send', 'Cancel' und der Moeglichkeitkeit zu beschreiben, was er denn gerade getan hat. Und ich denke nicht, dass es den User ueberfordern wird.

[Chromanoid]

man wird gezwungen, die dinger irgendwie zu behandeln. Sei es das ding weiter zu reichen (per throws in der methodendeklaration) oder per try/catch. Das gilt allerdings nur für nicht-runtime-exceptions (wie "datei wurde nicht gefunden", "auf dateisystem kann nicht zugegriffen werden", "zur datenbank konnte nicht verbunden werden"... o.ä.). man kann dafür getrost auf return errorcodes verzichten, was auch seine vorteile hat...
http://java.sun.com/docs/books/tutorial ... ntime.html