Was sind Entwicklerprobleme mit hilfreichen Fehlermeldungen? [geschlossen]

29

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 .

Moo-Juice
quelle
11
Wow, das ist eine ziemliche Schande.
George Marian
3
@ George, kannst du sagen, dass ich gerade viel Zeit damit verbracht habe, etwas aufzuspüren, das bei einem richtigen Fehler wirklich schneller hätte gelöst werden können? :)
Moo-Juice
4
Ich schlage vor, tief durchzuatmen, vielleicht Yoga und Meditation. :) (Das heißt, ich weiß genau, wie Sie sich fühlen.)
George Marian
2
+1 - "Zeichenfolge oder Binärdaten würden abgeschnitten" macht mich immer verrückt!
k25

Antworten:

22

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

George Marian
quelle
+1 Ich habe nicht einmal über den Aspekt der Informationsüberflutung nachgedacht.
Ryan Hayes
In meinem Beitrag habe ich erklärt, dass ich verstehen kann, warum manche das Gefühl haben, dass die Ausführlichkeit für einen Endbenutzer für sie unbrauchbar ist. Wollen Sie damit sagen, dass die Endbenutzer einer API (von ASP.NET-Adaptern) oder eines Datenbankmoduls (von SQL-Server) keine ausführlichen Fehler möchten ? Etwas, das uns möglicherweise Stunden an verlorener Zeit ersparen würde? Ich mochte das Wortspiel übrigens :)
Moo-Juice
1
@George, auch im Hinblick auf die Informationsüberflutung und die Nützlichkeit für den Endbenutzer, kann ich wieder ein Argument dafür sehen, dass der Benutzer eines Textverarbeitungsprogramms keinen vollständigen Stack-Trace erhält, damit er nicht einen braunen Hosenmoment hat und denken, sie haben das Internet gelöscht. Sie haben jedoch eine hervorragende Alternative mit komplexen Informationen in der Protokolldatei bereitgestellt. Jetzt muss nur noch eine Nachricht hinzugefügt werden For further information, see log20111701.txt. Dies wäre ein Schritt in die richtige Richtung.
Moo-Juice
2
@moo Letztendlich sage ich, dass es leicht zu kritisieren ist. (Ich weiß, ich mache es oft.) Ich versuche jedoch zu bedenken, dass es nicht unbedingt einfach ist zu sagen, wie viele Informationen Sie in eine Fehlermeldung aufnehmen sollten. Es gab viele Male, in denen ich detailliertere Informationen zurückgeben musste, als ich ursprünglich beim Debuggen erwartet hatte. Es gibt auch viele Male, in denen eine Fehlermeldung nicht so nützlich war, wie ich es beim Erstellen erwartet hatte.
George Marian
1
@moo Der Kern des Problems ist, dass es nicht immer offensichtlich ist, wie viele Informationen nützlich sind. Die Beispiele, die Sie zur Verfügung stellen, scheinen ziemlich offensichtlich. Es ist jedoch nicht einfach, dies auf den allgemeinen Fall auszudehnen.
George Marian
21

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.

David Thornley
quelle
+1 Bei vielen Framework- / API-Arten von Fehlern ist ein Teil des Problems, dass der Entwickler der Bibliothek den Kontext nicht kennt. Das heißt, OP scheint hauptsächlich mit den Fehlermeldungen "etwas stimmt nicht, aber ich werde Ihnen nicht sagen, wo, obwohl ich sie kenne" befasst zu sein. Ich denke, es ist Sicherheit, oder?
MIA
8

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.

Jon Hopkins
quelle
Ich verstehe, woher Sie in vielen Fällen von Endbenutzern kommen. Die in meinem ursprünglichen Beitrag beschriebenen Fälle können jedoch beim Schreiben von Code für Datenbanken häufig auftreten. Bei Endbenutzeranwendungen wie einem Textverarbeitungsprogramm oder einem Computerspiel sollten Fehler im Allgemeinen nur dann auftreten, wenn etwas Schlimmes passiert , und selbst dann kann der Fehler für den Endbenutzer möglicherweise nichts bedeuten ( Process Handle Raped By Spawned Injector, Quitting SYstem....). user: "wtf habe ich getan?`). Aber im Falle von SQL Server / ASP.NET hätte ich mehr Mühe geben können :)
Moo-Juice
@ Moo-Juice - ich denke das kommt auf die ganze "Fehlermeldung ist schwer" Sache an. Unter der Haube hat das, was tatsächlich in die Datenbank geworfen wird, nachdem der Optimierer es getan hat, nur eine vorübergehende Ähnlichkeit mit dem, was Sie darauf geworfen haben. Das Erkennen des Fehlers ist eine Sache, das Zurückverfolgen, was mit dem passiert ist, was Sie passiert haben, eine andere Sache, die absolut nicht trivial ist.
Jon Hopkins
Einige Fälle können nicht trivial sein. Ich habe irgendwo ein einfaches Stück Code, das den string/binary dataFehler abfängt, der alle Spalteninformationen aus dieser Tabelle abruft, die vergangenen Werte untersucht und anzeigt, welche Spalten verletzt worden wären. Das war trivial. Vielleicht zicke ich zu viel, weil meine Fallbeispiele trivial sind, aber ich verstehe vollkommen, dass dies nicht immer der Fall ist. Wie wir Spawned Injectors von Vergewaltigungsprozessen abhalten können, mag schwierig sein :)
Moo-Juice
6

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.

Ryan Hayes
quelle
Ah ja, guter Punkt. Das ist immer Anliegen der Kosten.
George Marian
Ich kann eine Kostenperspektive zugeben (und verdammt, das heißt nicht, dass ich es mögen muss). Ich kann nicht aus der Sicht der Entwickler von SQL Server oder ASP.NET sprechen, aber ich weiß , dass es nicht nehmen , dass viel zusätzlichen Aufwand einen Spaltennamen zur Verfügung zu stellen. Ich gebe zu, dass es für mein einfaches Beispiel in einer Stunde gelöst sein könnte. Dann gibt es die anderen 1000 Fehler, die generiert werden könnten. Aber sie könnten zumindest mit den üblichen anfangen :)
Moo-Juice
Natürlich kenne ich die Interna von SQL Server nicht - aber im Allgemeinen haben Sie diese Informationen zum Zeitpunkt der Fehlererkennung nicht immer zur Hand. Eine Formulierung wie "Zeichenfolge oder Binärdaten" zeigt deutlich, dass an der Fehlerstelle nicht einmal klar ist, ob der abgeschnittene Wert eine Zeichenfolge oder eine Zahl war ...
Ichthyo
Auf einer gewissen Ebene mag dies gültig sein, aber das gleiche Problem taucht sogar in einfachen Perl-Skripten auf, bei denen einfach $ hinzugefügt wird! zu der fehlermeldung wäre immens hilfreich. Es ist billiger (in Bezug auf die Entwicklerzeit), "die" $ path: $! "Zu schreiben, als das völlig nutzlose" die "Couldn't open $ path" "
William Pursell
6

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.

ThomasW
quelle
Es ist noch schlimmer: Während Sie Fehler an ganz bestimmten Punkten auslösen können, müssen Sie zum Behandeln von Fehlern mehrere Möglichkeiten in eine Klasse von Situationen unterteilen und diese mit einer einzigen Wiederherstellung behandeln. Diese Verallgemeinerung zwingt Sie häufig dazu, noch mehr der wenigen zusätzlichen Kontextinformationen zu verwerfen.
Ichthyo
Übrigens ... dieser Mechanismus führt zu einer ganzen Reihe lustiger Fehlermeldungen - im Sinne von "Schwerer Fehler -567 im Modul dwarf678: Kein Fehler erkannt"
Ichthyo
4
  • 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
StuperUser
quelle
Ich habe auf Ihren ersten Punkt geantwortet und eine Änderung der Ausführlichkeit in Bezug auf die Ausnahmen in Ihrem Code zugelassen. Ihr zweiter Punkt ist umstritten, da an diesem Punkt ein Fehler aufgetreten ist und die Geschwindigkeit kein entscheidender Faktor mehr ist (imho). Und wenn das Erzeugen einer ausführlichen Fehlermeldung vor dem Auslösen der Ausnahme eine Beeinträchtigung der Leistung erfordert, stimme ich zu. Verschieben Sie diesen Code nach dem Auslösen der Ausnahme. Ich sehe keinen dieser Punkte als ein gültiges Argument gegen die richtigen Fehlermeldungen :)
Moo-Juice
Es stimmt, ich nehme an, Sie können nach Informationen suchen, sobald etwas passiert ist, anstatt zu verfolgen, was Sie möglicherweise benötigen. Wenn Sie sich jedoch in verschachtelten Schleifen befinden, kann die Erfassung der Indizes / Indizes problematisch sein.
StuperUser
-1 für den ersten Punkt, dem ich nicht zustimme, +1 für den zweiten Punkt.
Jon Hopkins
1
@jon Vergleichen Sie eine allgemeine Fehlermeldung für Anmeldefehler mit genaueren Fehlermeldungen, die Ihnen tatsächlich mitteilen, was schief gelaufen ist. zB "Wir konnten diese Kombination aus Benutzername und Passwort nicht finden" vs "Sie haben ein falsches Passwort eingegeben." / "Dieser Benutzername existiert nicht." Ich scheine mich an eine Sicherheitsanfälligkeit in ASP.NET zu erinnern, bei der die Fehlermeldung tatsächlich zum Knacken von Verschlüsselungsschlüsseln hilfreich war.
George Marian
@ George - Ich stimme diesem Beispiel zu, glaube aber nicht, dass es weit verbreitet ist. Sobald Ihnen Zugriff auf eine Anwendung gewährt wurde, verschwindet ein gewisses Risiko, da Sie davon ausgehen können, dass die Person (a) autorisiert ist und (b) das meiste aus der tatsächlichen Anwendung herausholen kann.
Jon Hopkins
3

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 .

Ichthyo
quelle
Ich muss nicht zustimmen. Es weiß, dass etwas nicht stimmt (die Operation kann nicht ausgeführt werden). Zu wissen, dass etwas nicht stimmt, bedeutet zu wissen, warum es nicht stimmt. Diese Zeichenfolge ist für diese Spalte (oder eine Spalte in dieser Tabelle) zu groß. Es könnte mir sagen, ohne viel Arbeit. Es ist eine verdammte Enterprise-Datenbank-Engine. Es weiß . Diese Informationen werden jedoch nicht weitergegeben. Vorausgesetzt, der Programmierer kann eine Abfrage schreiben, die ausgeführt werden soll, nachdem festgestellt wurde, dass das Datenbankmodul dasselbe tun könnte. Dies sind keine geheimen undokumentierten Facetten. Nur eine beschissene Fehlermeldung :)
Moo-Juice
heh ... du solltest dein Argument auf Logik stützen, nicht auf Wunschdenken. Seit wann gibt es einen Computer wissen , was? Dies ist kein Hollywood-Kino. Ein Programm ist eine starre, vorab festgelegte Konfiguration, und wenn Ihre Annahmen nicht stimmen, haben Sie die Kontrolle verloren. Ist das wirklich so schwer zu begreifen? Ein Computer versteht das Programm nicht und kann es daher nicht verstehen, wenn es schief geht. Fast immer, wenn eine Konsistenzprüfung ausgelöst wird, wurde die Ausführung bereits mit Tausenden von Anweisungen fortgesetzt, und niemand weiß, welche Daten bereits beschädigt wurden. Alles was Sie tun können, ist den Schaden zu begrenzen
Ichthyo
2

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

Glenatron
quelle
1
Entschuldigung, das ist ziemlich unpraktisch. Wer wäre für die Verwaltung dieses Indexdokuments verantwortlich, damit es korrekt bleibt? Wie jede andere schriftliche Dokumentation, die vom Code getrennt ist, wäre sie veraltet und würde in dem Moment, in dem sie geschrieben wird, eine Quelle für neue Fehler finden.
Ichthyo
Im Gegenteil, so etwas könnte ein Skript aus dem Quellcode extrahieren, wenn jeder Fehler eine eindeutige Nummer hätte und die Beschreibung jedes Fehlers auch im Code entweder in Form eines (speziell formatierten) Kommentars oder als Zeichenfolge. Das Dokument wird also bei jedem Build automatisch generiert. Die extrahierte Nachricht könnte dann etwas detaillierter sein als alles, was der Endbenutzer sehen soll. Keine schlechte Idee!
Jeanne Pindar
Sie benötigen dazu kein Skript - viele Laufzeitsysteme können die Zeilennummer oder ähnliche Informationen protokollieren. Leider hilft dies beim ursprünglichen Problem nicht weiter, da wir nur wissen, wo eine Ausnahme festgestellt wurde, aber nicht wissen, was schief gelaufen ist . Letzteres herauszufinden, nennt man Debugging - in der Praxis ist dies eine mehr oder weniger mühsame und arbeitsintensive Aufgabe des Menschen.
Ichthyo
Ich bin mit @Jeanne - einfach genug, um in den Code aufzunehmen oder einen zentralen Index im Code mit dem Fehlercode und deren Interpretation zu haben. Wenn Sie wissen, wo eine Ausnahme festgestellt wurde, kann dies ausreichen, um Sie darauf aufmerksam zu machen, dass irgendwo ein Problem mit der Umgebung vorliegt, und nicht auf etwas im Code, das überprüft werden muss.
Glenatron
2

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.

GWLlosa
quelle
@GWLlosa, das ist eine großartige Antwort und eine, die ich nicht in Betracht gezogen hatte. Das heißt (und ich kann hier kein vollständiges Codebeispiel angeben), wenn ich diese IOException erhalte, bevor ich meine auslöse, GenericExceptionkann ich 1) das ProcessesSubsystem nach einer Liste von Prozessen fragen . 2) Fragen Sie jeden Prozess, welche Datenbank sie verwenden. 3) Ordnen Sie den Prozess der Datenbank zu, die der zu überschreibenden zugeordnet ist. 4) Lösen Sie eine DatabaseInUse(dbName, processName, applicationNameAusnahme aus. :)
Moo-Juice
1
Sicherlich möglich; Der Code zum Anpassen der Datenbank an den Prozess (insbesondere über das Netzwerk) kann jedoch selbst kompliziert / langsam / fehleranfällig sein, was zu zusätzlicher Frustration führen kann ("Ich versuche nur, die lokale Datenbank wiederherzustellen (* #% ^! % file !!!! WARUM SORGE ICH DAFÜR, DASS DIE NETZWERKANTEILE NICHT ZUGÄNGLICH SIND! ??!?! ")
GWLlosa
1
@ Moo-Juice: was du vorschlägst hört sich ganz naiv an. In einer massiven Multithread-Umgebung wie einer Datenbank können Sie nicht einfach einen globalen Dienst aufsuchen, um eine Liste mit "all xyz" zu erhalten. Sogar um mit einem anderen Dienst in einem anderen Thread zu sprechen, benötigen Sie eine Sperre, die zu einem Deadlock des gesamten Systems führen kann, andere Daten beschädigen oder zumindest zusätzliche Fehler verursachen kann, die Sie dann ebenfalls behandeln müssen ....
Ichthyo
1
Dieses Beispiel ist in der Tat sehr lehrreich: Typischerweise kann man in einem solchen Catch-Handler nicht einmal genau sagen, welcher Teil des try-Blocks fehlgeschlagen ist (normalerweise gibt es mehrere Teile, die eine IOException verursachen können). Außerdem ist es sehr wahrscheinlich, dass Sie an diesem Ort den Namen der Datei nicht sagen können, damit Sie nicht erkennen können, welche logische Tabelle dieser Datei entspricht.
Ichthyo
@Ichthyo, keine Beleidigung, aber ich denke nicht, dass es überhaupt naiv ist. Ich bitte das Datenbankmodul nicht, das System zu sperren, um mir mitzuteilen, welcher Prozess noch ein Handle für eine Datenbank hat. Ich bitte nicht darum, das gesamte Unternehmen zum Erliegen zu bringen. Wenn es eine einfache Antwort sein muss, zeigt dies zunächst einen grundlegenden Konstruktionsfehler des Datenbankservers. Denken Sie daran, es soll so konzipiert sein, dass relevante Informationen auf schnellstmögliche Weise wiedergegeben werden. Um es die Frage zu stellen "Wer?" Sollte wirklich nicht so naiv sein, wie du sagst :)
Moo-Juice
2

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

grinsender Mann
quelle
+1, absolut fantastisch! Es ist die Art von Fehler, die Sie dazu bringt, einfach aufzugeben und Hühner in Fidschi aufzuziehen.
Moo-Juice
In der Tat ist diese Fehlermeldung zu 100% korrekt. Wenn Sie eine freundlichere Nachricht mit mehr Conetxt wünschen, müssen Sie einige Vermutungen und Heuristiken einbauen. Auf diese Weise können Sie die Möglichkeit irreführender Fehlermeldungen hinzufügen .
Ichthyo
0

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.

Mctylr
quelle
0

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!").

kizzx2
quelle