Was sind Entwicklerprobleme mit hilfreichen Fehlermeldungen? [geschlossen]

Es weiterhin verblüfft mich , dass in der heutigen Zeit, Produkte , die Jahre der Nutzung auf dem Buckel haben, von einem Team von Profis, noch bis heute - nicht hilfreich Fehlermeldungen an den Benutzer zur Verfügung zu stellen. In einigen Fällen kann das Hinzufügen von wenigen zusätzlichen Informationen dem Benutzer stundenlange Probleme ersparen.

Ein Programm, das einen Fehler generiert, hat ihn aus einem bestimmten Grund generiert. Es hat alles zur Verfügung, um den Benutzer so weit wie möglich zu informieren, warum etwas fehlgeschlagen ist. Und doch scheint die Bereitstellung von Informationen zur Unterstützung des Benutzers eine niedrige Priorität zu haben. Ich denke, das ist ein großes Versagen.

Ein Beispiel ist von SQL Server. Wenn Sie versuchen, eine Datenbank wiederherzustellen, die gerade verwendet wird, können Sie das zu Recht nicht. SQL Server weiß, welche Prozesse und Anwendungen darauf zugreifen. Warum kann es keine Informationen zu den Prozessen enthalten, die die Datenbank verwenden? Ich weiß, dass nicht jeder ein Applicatio_NameAttribut für seine Verbindungszeichenfolge übergibt , aber sogar ein Hinweis auf die betreffende Maschine könnte hilfreich sein.

Ein weiterer Kandidat, auch SQL Server (und MySQL), ist die schöne string or binary data would be truncatedFehlermeldung und Entsprechungen. Viel Zeit, eine einfache Durchsicht der SQL-Anweisung, die generiert wurde, und die Tabelle zeigt, welche Spalte der Schuldige ist. Dies ist nicht immer der Fall, und wenn das Datenbankmodul den Fehler erkannt hat, warum kann es uns dann nicht diese Zeit sparen und uns nur sagen, um welche verdammte Spalte es sich handelt? In diesem Beispiel könnten Sie argumentieren, dass die Überprüfung möglicherweise einen Leistungseinbruch zur Folge hat und dies den Verfasser behindern würde. Gut, das kaufe ich mir. Wie wäre es, wenn das Datenbankmodul nachträglich einen schnellen Vergleich zwischen den zu speichernden Werten und den Spaltenlängen durchführt, sobald es weiß, dass ein Fehler vorliegt. Zeigen Sie das dann dem Benutzer an.

ASP.NETs schreckliche Tabellenadapter sind ebenfalls schuld. Es können Abfragen ausgeführt und eine Fehlermeldung ausgegeben werden, die besagt, dass irgendwo eine Einschränkung verletzt wird. Dank dafür. Es ist Zeit, mein Datenmodell mit der Datenbank zu vergleichen, da die Entwickler zu faul sind, auch nur eine Zeilennummer oder Beispieldaten bereitzustellen. (Für das Protokoll, ich würde nie dieses Datenzugriffsmethode verwenden , durch Wahl , es ist nur ein Projekt , das ich geerbt haben!).

Immer wenn ich eine Ausnahme von meinem C # - oder C ++ - Code auslöse, stelle ich dem Benutzer alles zur Verfügung, was ich zur Verfügung habe. Es wurde die Entscheidung getroffen, es zu werfen. Je mehr Informationen ich geben kann, desto besser. Warum hat meine Funktion eine Ausnahme ausgelöst? Was wurde übergeben und was wurde erwartet? Ich brauche nur ein wenig länger, um den Text einer Ausnahmebotschaft mit einer Bedeutung zu versehen. Zur Hölle, es hilft mir nur, während ich mich entwickle, weil ich weiß, dass mein Code Dinge auslöst, die von Bedeutung sind.

Man könnte argumentieren, dass dem Benutzer keine komplizierten Ausnahmemeldungen angezeigt werden sollten. Ich bin damit zwar nicht einverstanden, aber es ist ein Argument, das sich leicht beruhigen lässt, wenn Sie abhängig von Ihrem Build eine unterschiedliche Ausführlichkeit haben. Selbst dann sind die Benutzer von ASP.NET und SQL Server keine typischen Benutzer und würden etwas voller Ausführlichkeit und leckerer Informationen bevorzugen, da sie ihre Probleme schneller aufspüren können.

Warum halten Entwickler es heutzutage für in Ordnung, im Fehlerfall so wenige Informationen wie möglich bereitzustellen?

Es ist 2011 Jungs, kommen auf .

Obwohl es viele Beispiele für schlechte Fehlermeldungen gibt, die einfach nicht auftreten sollten, müssen Sie bedenken, dass es nicht immer möglich ist, die gewünschten Informationen bereitzustellen.

Es besteht auch die Besorgnis, zu viele Informationen preiszugeben, was zu Fehlern führen kann. (Ich verspreche Ihnen, dass das Wortspiel nicht beabsichtigt war, aber ich entferne es jetzt nicht, da ich es bemerkt habe.)

Manchmal gibt es auch die Tatsache, dass eine komplexe Fehlermeldung für den Endbenutzer nutzlos ist. Abstellgleis mit Informationsüberflutung ist nicht unbedingt ein guter Ansatz für Fehlermeldungen. (Das kann am besten für die Protokollierung gespeichert werden.)

Entwickler sind nicht die richtigen Leute, um Fehlermeldungen zu schreiben.

Sie sehen die Anwendung aus dem falschen Blickwinkel. Sie wissen sehr genau, was im Code schief gelaufen ist, nähern sich der Software jedoch häufig nicht, um etwas zu erreichen. Daher sind wichtige Informationen für den Entwickler nicht unbedingt wichtige Informationen für den Benutzer.

Die karitative Sichtweise:

• Der Entwickler arbeitete eng mit dem Code zusammen und bemühte sich, jemanden zu verstehen, der nicht mit dem Code umgehen konnte. Aus diesem Grund denken sie, dass die Fehlermeldungen in Ordnung sind. Sie haben einfach keinen guten Bezugsrahmen, anhand dessen sie beurteilt werden können.

• Intelligente Fehlermeldungen sind eigentlich schwer zu machen. Sie schreiben sie nicht nur, sondern Sie müssen alles herausfinden, was schief gehen könnte, die Wahrscheinlichkeit einschätzen und der Person, die die Nachricht liest, nützliche Informationen (die sich mit ziemlicher Sicherheit je nach Kontext unterscheiden) zurückgeben, damit sie sie beheben können.

• Für die meisten Anwendungen ist es schwierig, eine gute Argumentation für diese Art von Aufgaben zu finden, wie es sich der nächste Entwickler wünscht, da Fehler nicht so häufig auftreten. Außerdem, wenn Sie diese zusätzliche Zeit hätten, sollten Sie es nicht damit verbringen, die Fehler zu stoppen, anstatt darüber zu berichten?

Die gemeinnützige Sichtweise:

• Fehlermeldungen und Fehlerbehandlung sind langweilig, es gibt viel interessantere Dinge, an denen ich arbeiten muss, und mein Chef ist auf dem Rücken, was das nächste angeht. Ich verstehe diesen Code, mir geht es gut, der nächste wird es am Ende klären und ich werde bis dahin hier raus sein, also ist es nicht mein Problem.

Die Realität liegt wahrscheinlich irgendwo in der Mitte, obwohl meine Erfahrung mir sagt, dass es viel mehr die erstere als die spätere ist - im Grunde genommen ist es ziemlich schwierig und erfordert einiges an Anstrengung, um mit etwas fertig zu werden, was wahrscheinlich nicht passieren wird.

Leider mehr hilfreich Fehlermeldungen kosten Entwickler Zeit, das Unternehmen Geld entspricht. Produkte sind teuer genug, um sie so wie sie sind zu bauen. Ja, es wäre fantastisch, hilfreiche Fehlermeldungen zu haben, und ich bin damit einverstanden, dass weitere nützliche enthalten sein sollten. Es ist jedoch nur eine Tatsache des Lebens, dass Sie, wenn Sie unter einer Frist sind und Geld auf dem Spiel steht, etwas kürzen müssen. "Schönere Fehlermeldungen", wie Manager es vielleicht sehen, werden wahrscheinlich das erste sein, was Sie tun müssen.

Ich bin damit einverstanden, dass Fehlermeldungen so spezifisch wie möglich sein sollten.

Ein Grund für generische Fehlermeldungen ist wahrscheinlich die Verwendung von Fehlercodes. Bei der Verwendung von Ausnahmen können Sie alle in der Fehlermeldung erforderlichen Angaben machen. Bei Verwendung von Rückkehrcodes ist kein Platz zum Codieren eines Spaltennamens vorhanden. Möglicherweise wird der Fehler von einer generischen Funktion behandelt, die den Kontext nicht kennt und den Fehlercode einfach in eine Zeichenfolge übersetzt.

• Manchmal können zu viele Informationen ein Sicherheitsrisiko darstellen. Sie wissen nicht, wer die Fehlermeldung liest
• Manchmal ist der Vorgang, der die Ausnahme ausgelöst hat, so komplex, dass es unmöglich ist, eine aussagekräftige Meldung zu erhalten, ohne die Geschwindigkeit / Komplexität des Codes zu beeinträchtigen

Generell sollten Sie berücksichtigen, dass jeder Fehler oder jede Ausnahmesituation - genau das - außergewöhnlich ist. Es ist ein Querschnitt durch das geplante und gestaltete Verfahren. Es ist nicht kompatibel mit der Art und Weise, wie die Dinge funktionieren sollen. Wenn dies nicht der Fall wäre, wäre es nicht erforderlich, mit einem Fehlerabbruch auszusteigen.

Wir Programmierer sind geschult, um für den Selbstschutz dieses geplanten Verfahrens zu sorgen. Aus diesem Grund führen wir routinemäßig einige Überprüfungen der geistigen Gesundheit durch, um unsere Annahmen zu überprüfen. Wenn diese Plausibilitätsprüfungen fehlschlagen, wissen wir nur, dass der Plan irgendwie fehlgeschlagen ist ...

Ihre Forderung - aus Anwendersicht mag sie durchaus vernünftig aussehen - kann nicht erfüllt werden, wenn Sie die Realität eines solchen Systems in Betracht ziehen. Sie fordern eine ordnungsgemäße Erklärung mit gut organisierten und geeigneten Informationen. Darüber hinaus bitten Sie sogar darum, dass diese Präsentation so erfolgt, dass sie in das allgemeine Anwendungs- / Handhabungsdesign passt. Offensichtlich existiert diese Information irgendwo im System. Offensichtlich existiert es dort sogar in einer geordneten und gut organisierten Weise (lasst es uns hoffen). ABER an dem Punkt, an dem der Fehler auftritt, hat niemand geplant, diese Informationen zur Verfügung zu stellen. Ein Fehler ist immer ein teilweiser Kontrollverlust.Dieser Kontrollverlust kann auf verschiedenen Ebenen auftreten. Möglicherweise verhält sich das System zur Laufzeit anders als geplant. Es könnte aber auch sein, dass die tatsächliche Umsetzung in den Details viel schwieriger und anders ausfiel als geplant, und es gab keine geregelte Regelung, um diese Situation zufriedenstellend zu handhaben. Auch dies ist ein teilweiser Kontrollverlust.

Um dies mit dem konkreten Beispiel in Verbindung zu bringen, das Sie angegeben haben: Wenn zum Zeitpunkt des Fehlers der Name und der Typ der Tabellenspalte sowie die Länge des erforderlichen Speicherplatzes bekannt wären, gäbe es keinen Grund dafür einen Fehler auslösen, nicht wahr? Wir könnten einfach die Situation beheben und wie geplant vorgehen. Die Tatsache, dass wir gezwungen sind, einen Fehler zu machen, zeigt uns, dass die Dinge schief gelaufen sind. Die bloße Tatsache, dass diese Informationen nicht zur Hand sind, ist die Ausnahme .

Was ich hier schreibe, mag als selbstverständlich und nur gesunder Menschenverstand erscheinen. Aber in Wirklichkeit ist es extrem schwer zu begreifen. Wir versuchen ständig, es durch Anwendung moralischer Kategorien zu verstehen - so wie es einen Schuldigen geben muss, es muss eine schlechte faule Person geben, die sich nicht um den armen Benutzer kümmert, es muss gierige Geschäftsleute geben, die einen Weg zu billigen Kalkulationen gefunden haben. All dies ist völlig daneben

Die Möglichkeit eines Kontrollverlusts ergibt sich aus der Tatsache, dass wir die Dinge in einer geplanten und geordneten Weise tun .

Ich arbeite als Supportingenieur für eine Softwarefirma und oft sehen wir Fehlermeldungen, die für uns neu sind. Wenn ich diese an unser Entwicklungsteam zurückverweise, müssen sie häufig in der Quelle der Anwendung nach der Nachricht suchen.

Es scheint mir, dass es viel Zeit spart, wenn das Entwicklerteam einem Fehlernachrichtenindexdokument oder einer Datenbank eine Notiz hinzufügt, wenn es eine neue hinzufügt, die es erstellt Wir finden die Ursache für Kundenprobleme viel schneller und sparen ihnen auch Zeit ...

Das Problem, das Sie dort sehen, ist tatsächlich eine der Nebenwirkungen einer ordnungsgemäßen Kapselung und des Versteckens von Informationen.

Moderne Systeme sind äußerst kompliziert. Es ist unwahrscheinlich, dass ein durchschnittlicher Entwickler in der Lage ist, ein mentales Modell des gesamten Systems von der Benutzeroberfläche bis zur unformatierten Binärdatei im Kopf zu behalten, während er eine bestimmte Aufgabe programmiert.

Während sich ein Entwickler hinsetzt und beispielsweise das Bit codiert, das eine Datenbankdatei wiederherstellt, ist sein mentales Modell vollständig mit den Bits gefüllt, die den Vorgang des Wiederherstellens einer Datenbankdatei umgeben. Er muss (und ich vermute, ich habe diesen Code nicht geschrieben) eine Datei lesen, Eigenschaften überprüfen, Versionen lesen, vorhandene Daten sichern, eine Strategie zum Zusammenführen / Überschreiben auswählen usw. Sehr wahrscheinlich, wenn es überhaupt eine Übergabe gibt Berücksichtigung der Benutzeroberfläche, die in der Fehlerzeichenfolge enthalten ist, die er in einem Ausnahmehandler schreibt. So etwas wie:

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

In diesem Beispiel sind die hilfreichen Informationen, nach denen Sie im Hinblick auf Prozesse fragen, die die Datei oder sogar andere Threads in der Datenbank verwenden, (programmgesteuert) vollständig ungültig. Es kann Hunderte von Klassen geben, die sich mit DB-Dateien befassen. Das Importieren von Informationen über jeden anderen Prozess, der die Dateien verwendet, oder von Funktionen zum Zugreifen auf das Dateisystem und zum Anzeigen der anderen ausgeführten Prozesse (vorausgesetzt, diese Prozesse befinden sich sogar auf DIESEM Computer) in diese Klassen würde zu einer so genannten undichten Abstraktion führen . Die Produktivität ist mit direkten Kosten verbunden.

So können solche Fehler heutzutage fortbestehen. Offensichtlich KÖNNTEN sie alle repariert werden; In vielen Fällen ist jedoch viel mehr Aufwand erforderlich, als man denkt (in diesem Fall muss diese Funktion möglicherweise die Aufzählung von Netzwerkverbindungen und Freigaben durchlaufen, um festzustellen, ob ein Remotecomputer diese Datenbankdatei für einige verwendet) Grund) und die Kosten sind alles andere als trivial.

Mein Favorit war (Ende der 70er Jahre) der Univac Fortran IV-Compiler, der beim Lesen von Nicht-Ziffern getreu angekündigt wurde

Es wurde versucht, bedeutungslose Daten zu interpretieren

Ich glaube, die Mehrheit der Fehlermeldungen sind tatsächlich Programmierer (selbst) orientierte verherrlichte Debugging-Code / printf-Anweisungen.

Wenn Sie benutzerorientierte Fehlermeldungen schreiben, müssen Sie wissen, wer Ihr Benutzer ist und was er wissen möchte. Während des Schreibens von Code kann ein Entwickler eher eine für ihn selbst nützliche Fehlermeldung schreiben, um entweder den Code zu debuggen, den er gerade schreibt, oder für bekannte oder vorherrschende Anwendungsfälle.

Der Wechsel vom Schreiben von Code zum Entwerfen eines Textabschnitts der Benutzeroberfläche (oder Benutzererfahrung) ist ein Kontextwechsel. In großen Anwendungen, z. B. mehrsprachigen Anwendungen, die bedeuten könnten, dass sie an eine andere Person oder ein anderes Team (Benutzeroberfläche, Übersetzung) weitergegeben werden, anstatt vollständig vom Entwickler behandelt zu werden. Wenn der Entwickler den Kontext der Nachricht also nicht sorgfältig erläutert, können wichtige Details vorliegen leicht verloren.

Natürlich wird das Überprüfen und Verifizieren der Fehlerbehandlung oft als eine niedrige Priorität angesehen, solange Fehler und Ausnahmen behandelt (dh abgefangen) werden, ohne dass viel Gewicht darauf gelegt wird. Es ist ein geistig nicht lohnender Ort, an dem Entwickler oder QA die Codebasis auswerten können, da Fehlerzustände häufig mit einer negativen Konnotation (dh Fehler oder Misserfolg) verbunden sind.

Ich denke, der Grund dafür ist, dass die Fehlerberichterstattung / -behandlung immer als nachträglicher Gedanke erfolgt . Auch wenn sie nicht ganz nachdenklich sind, sind sie im Gesamtdesign meist Bürger zweiter Klasse.

Moderne Software besteht normalerweise aus mehreren Schichten. Wenn Ihre Fehlerberichtslogik ohne allzu große Überlegungen in Eile festgelegt wird, ist es oft schwierig, alle Informationen zu erfassen, die für die Anzeige nützlicher Fehlermeldungen erforderlich sind.

Der Fehler wird beispielsweise im Back-End abgefangen, benötigt jedoch einige Informationen aus höheren Ebenen, um eine umfassende Fehlermeldung zu erstellen. Die meisten guten Fehlermeldungen benötigen Informationen aus fast allen Ebenen (um einen umfassenden Überblick über die Vorgänge im System zu erhalten). Die ideale Fehlermeldung würde so aussehen: "OK, wir haben zuerst eine Zeichenfolge erhalten, die dann durch den Parser geleitet wurde, der etwas Komisches ergab. Vielleicht möchten Sie dort nachsehen. Wie auch immer, die Zeichenfolge wurde weiter unten übergeben ..."

Dies würde häufig eine unnötige Kopplung erfordern, wenn der Fehlerberichterstattungsmechanismus während der Entwurfsphase nicht von erstklassiger Qualität war. Ich denke, die meisten Leute finden, dass zu viel Arbeit für etwas zu tun ist, das nicht beeindruckend aussieht (wer sagt gerne "Sehen? Mein Programm ist abgestürzt und die Fehlermeldung ist nützlich!").