Sollten Beispiele - auch Anfängerbeispiele - den Fehlerbehandlungscode enthalten?

Ich denke, es könnte eine Verbesserung sein, wenn wir bei der Eingabe von Beispielcode zumindest Kommentare hinzufügen, die sagen, dass Sie an einigen Stellen Fehlerbehandlungscode einfügen müssen. Dies könnte jemandem, der diesen Code verwendet, zumindest helfen, sich daran zu erinnern, dass er eine Fehlerbehandlung durchführen muss. Dadurch bleibt der zusätzliche Code für die Fehlerbehandlung erhalten, aber die Idee, dass Code zur Fehlerbehandlung benötigt wird, wird noch verstärkt.

Jeder mitgelieferte Beispielcode wird mindestens einmal in den Produktionscode kopiert. Seien Sie also beim Schreiben am besten.

Abgesehen von der Frage, ob Sie den Code überfluten sollten, wenn Sie einen Codierpunkt demonstrieren, wird die Frage, wie wie Sie wählen, den Fehler in Ihrem Beispielcode zu behandeln?

Das heißt, was machst du? Was für eine Anwendung tödlich ist, ist für andere nicht tödlich. z.B. Wenn ich einige Informationen von einem Webserver nicht abrufen kann (sei es ein 404-Fehler oder ein nicht reagierender Server), kann das fatal sein, wenn Sie ohne diese Daten nichts tun können. Aber wenn diese Daten eine Ergänzung zu dem sind, was Sie tun, dann können Sie vielleicht ohne es leben.

So kann das oben erwähnte darauf hinweisen, den Fehler einfach zu protokollieren. Das ist besser, als den Fehler vollständig zu ignorieren. Aber ich denke oft besteht die Schwierigkeit darin, zu wissen, wie / wann (und wann nicht) man sich von einem Fehler erholen kann. Vielleicht ist das ein ganz neues Tutorial für sich.

Beispiele sollten illustrativ sein. Sie sollten immer zeigen, dass der Punkt mit möglichst wenig Ablenkung klar gemacht wird. Hier ist ein Meta-Beispiel:

Nehmen wir an, wir möchten eine Nummer aus einer Datei lesen, 3 hinzufügen und sie auf der Konsole ausgeben. Wir müssen ein paar Dinge demonstrieren.

Worth, aber richtig, außer es gibt ein paar Dinge, die schief gehen könnten. Erstens, was ist, wenn die Datei nicht existiert? Was ist, wenn es existiert, aber keine Nummer enthält?

So zeigen wir, wie die Fehler behandelt werden.

Nach einigen Iterationen, die zeigen, wie mit den Fehlern umzugehen ist, die in diesem Fall durch Dateihandling und Parsing ausgelöst werden. Natürlich möchten wir eine eher pythische Art und Weise zeigen, die try-Klausel auszudrücken. Jetzt lassen wir die Fehlerbehandlung fallen, weil wir das nicht demonstrieren.

Zuerst müssen wir die unnötigen zusätzlichen Variablen entfernen.

Da wir nicht darüber schreiben und es auch keine teure Ressource in einem langwierigen Prozess ist, ist es in der Tat sicher, es offen zu lassen. Es wird geschlossen, wenn das Programm beendet wird.

Aber manche mögen argumentieren, dass das eine schlechte Angewohnheit ist und es gibt eine schönere Art, mit diesem Problem umzugehen. Wir können einen Kontext verwenden, um es ein wenig klarer zu machen. Natürlich würden wir erklären, dass eine Datei am Ende eines With Blocks automatisch geschlossen wird.

Und nun, nachdem wir alles ausgedrückt haben, was wir wollten, zeigen wir am Ende des Abschnitts ein vollständiges Beispiel. Außerdem werden wir eine Dokumentation hinzufügen.

Das ist eigentlich die Art, wie ich normalerweise Reiseführer sehe, und es funktioniert sehr gut. Ich werde normalerweise frustriert, wenn irgendein Teil fehlt.

Ich denke, die Lösung ist irgendwo in der Mitte. Wenn Sie eine Funktion definieren, um das Element 'x' in der Liste 'y' zu finden, tun Sie etwas wie folgt:

Es muss nicht explizit angegeben werden, was eine Eingabe gültig macht, nur dass der Leser wissen sollte, dass die Logik gültige Eingaben voraussetzt.

Nicht immer stimme ich mit BWK nicht überein, aber ich denke, Anfängerbeispiele besonders sollten Fehlerbehandlungscode zeigen, da Anfänger damit große Schwierigkeiten haben. Erfahrenere Programmierer können die Fehlerbehandlung als gelesen betrachten.

Eine Idee, die ich hatte, wäre, irgendwo in Ihrem Beispielcode eine Zeile wie die folgende einzufügen:

All dies verhindert, dass der Code "von der Stange" kompiliert wird, für jeden, der ihn blind kopiert und einfügt (da DONT_FORGET_TO_ADD_ERROR_CHECKING() offensichtlich nirgendwo definiert ist). Aber es ist auch ein Ärger und könnte als unhöflich angesehen werden.

Ich würde sagen, dass es vom Kontext abhängt. In einem Blogeintrag oder Lehrbuch würde ich mich auf den Code konzentrieren, um die gewünschte Funktionalität auszuführen oder zu demonstrieren. Ich würde wahrscheinlich das obligatorische Nicken der Fehlerbehandlung geben, vielleicht sogar einen Scheck einreichen, aber den Code mit einer Ellipse stubben. Im Unterricht können Sie viel Verwirrung stiften, indem Sie zu viel Code einfügen, der sich nicht direkt auf das Thema konzentriert. Insbesondere in SO scheinen kürzere (aber vollständige) Antworten vorzuziehen, so dass auch die Handhabung von Fehlern mit "einer Handbewegung" in diesem Zusammenhang besser geeignet ist.

Wenn ich ein Codebeispiel zum Download zur Verfügung stellte, würde ich es im Allgemeinen so vollständig wie möglich machen und eine angemessene Fehlerbehandlung beinhalten. Die Idee hier ist, dass zum Lernen der Person immer zurück zum Tutorial / Blog gehen und das verwenden kann, um den Code als tatsächlich implementiert zu verstehen.

Nach meiner persönlichen Erfahrung ist dies eines der Probleme, die ich bei der typischen Darstellung von TDD habe - normalerweise sehen Sie nur die entwickelten Tests, um zu überprüfen, ob der Code im Hauptausführungspfad erfolgreich ist. Ich würde gerne sehen, dass mehr TDD-Tutorials Tests für alternative (Fehler-) Pfade entwickeln. Dieser Aspekt des Testens ist meines Erachtens am schwierigsten, da man nicht nachdenken muss, was passieren sollte, sondern vor allem, was schief gehen könnte.

Fehlerbehandlung ist ein Paradigma für sich; es sollte normalerweise nicht in Beispielen enthalten sein, da es ernsthaft den Punkt korrumpiert, auf den der Autor zu stoßen versucht.

Wenn der Autor Wissen über Fehlerbehandlung in einer bestimmten Domäne oder Sprache weitergeben möchte, würde ich als Leser lieber ein anderes Kapitel haben, das alle dominanten Paradigmen der Fehlerbehandlung umreißt und wie dies den Rest der Kapitel betrifft.

Ich denke nicht, dass die Fehlerbehandlung im Beispiel sein sollte, wenn sie die Logik verdeckt. Aber einige Fehlerbehandlung ist nur das Idiom, einige Dinge zu tun, und in diesem Fall enthalten sie.

Auch wenn darauf hingewiesen wird, dass die Fehlerbehandlung hinzugefügt werden muss. Für die Liebe der Gottheit weisen Sie auch darauf hin, welche Fehler behandelt werden müssen.

Dies ist der frustrierendste Teil beim Lesen einiger Beispiele. Wenn Sie nicht wissen, was Sie tun (was wir vom Leser des Beispiels annehmen müssen ...), wissen Sie nicht, nach welchen Fehlern Sie suchen sollen. Was den Vorschlag "Fehlerbehandlung hinzufügen" in "dieses Beispiel ist nutzlos" verwandelt.

Ein Ansatz, den ich gesehen habe, insbesondere in Erweiterte Programmierung in der UNIX-Umgebung und UNIX Network Programming ist es, Anrufe mit Fehlerprüfcode zu umhüllen und dann die Wrapper im Beispielcode zu verwenden. Zum Beispiel:

dann, im aufrufenden Code:

Auf diese Weise können Sie die Fehlerbehandlung anzeigen, während der Fluss des Aufrufcodes klar und prägnant ist.

Nein, es sei denn, der Zweck des Beispiels besteht darin, einen Aspekt der Ausnahmebehandlung zu demonstrieren. Das ist ein Ärgernis von mir - viele Beispiele versuchen, Best Practices zu demonstrieren und am Ende das Beispiel zu verdunkeln und zu verkomplizieren. Ich sehe dies die ganze Zeit in Codebeispielen, die damit beginnen, eine Reihe von Interfaces und Vererbungsketten zu definieren, die für das Beispiel nicht notwendig sind. Ein Paradebeispiel dafür, dass es zu kompliziert war, war ein Praktikum, das ich letztes Jahr auf der TechEd gemacht habe. Das Labor befand sich auf Linq, aber der Beispielcode, den ich schreiben wollte, erstellte eine mehrstufige Anwendung für keinen Zweck.

Beispiele sollten mit dem einfachsten möglichen Code beginnen, der den Punkt veranschaulicht, und dann in die Praxis und in die Praxis übergehen.

Wenn ich Code-Beispiele von Stellenbewerbern anfordere, sind fast alle vorsichtig, um ihr Wissen über die Handhabung von Ausnahmen zu demonstrieren:

Ich habe mit jeder Methode Hunderte von Codezeilen erhalten. Ich habe begonnen, Bonuspunkte für diejenigen zu vergeben, die throw verwenden; anstatt zu werfen ex;

Beispielcode muss keine Fehlerbehandlung enthalten, aber ansonsten sollten geeignete sichere Codierungstechniken demonstriert werden. Viele Webcode-Snippets verletzen die OWASP Top Ten.