npm Richtlinien für Rückruffehler

8

Ich habe die npm-Codestil-Richtlinien gelesen und bin auf Folgendes gestoßen sehr kryptischer Vorschlag:

  

Sei sehr vorsichtig, niemals etwas zu werfen. Es ist schlimmer als nutzlos. Senden Sie die Fehlermeldung als erstes Argument an den Rückruf zurück.

Was genau meinen sie und wie implementiert man dieses Verhalten? Schlagen sie vor, die Callback-Funktion in sich selbst aufzurufen?

Hier ist, was ich über die Verwendung der asynchronen fs.readdir -Methode denken könnte.

%Vor%     
chharvey 30.05.2015, 02:44
quelle

2 Antworten

6

Was sie sagen wollen, ist, dass Sie Ihre Module so entwerfen sollten, dass die asynchronen Funktionen keine Fehler zum Abfangen liefern, sondern innerhalb eines Callbacks behandelt werden (wie im von Ihnen bereitgestellten Beispiel fs.readdir ). .

Also zum Beispiel sagen sie, dass Sie Ihr Modul wie folgt gestalten sollten:

%Vor%

Sie möchten, dass Sie es so entwerfen, dass der Endbenutzer den Fehler innerhalb des Callbacks behandeln kann, anstatt eine try / catch-Anweisung zu verwenden ... Zum Beispiel, wenn wir das example -Objekt verwenden:

%Vor%

Dies würde {"message": "Data is not a string!"} protokollieren, da für die Daten kein typeof gleich "string" ist.

Hier ist ein Beispiel dafür, was Sie vermeiden sollten:

Sie möchten nicht, dass Sie Fehler ausgeben, wenn Sie Ihren asynchronen Callback zur Verfügung haben ... Nehmen wir an, wir haben unser Modul so umgestaltet, dass die Methode logString einen Fehler auslöst, anstatt es an einen Callback zu übergeben ... So:

%Vor%

Damit müssen wir die gesamte try / catch-Anweisung ausführen, sonst erhalten Sie einen nicht gefundenen Fehler:

%Vor%

Abschließende Gedanken / Zusammenfassung:

Der Grund, warum ich denke, NPM schlägt diese Methode vor, weil sie innerhalb einer asynchronen Methode einfacher zu handhaben ist.

NodeJS und JavaScript im Allgemeinen haben gerne eine asynchrone Umgebung, also ist es schön, alles kompakt an einem Ort zu haben, Fehlerbehandlung und alles.

Mit dem try / catch ist es nur noch ein weiterer Schritt, den Sie ausführen müssen, wenn es leicht innerhalb des Callbacks behandelt werden könnte (wenn Sie es asynchron entwerfen, was Sie tun sollten).

    
user3117575 30.05.2015, 02:58
quelle
2

Ja, das würde eine Endlosschleife verursachen. Sie sprechen jedoch nicht über diese Art von Rückruf. Stattdessen referenziert npm die Callbacks, die für die Interaktion mit Ihrem Modul verwendet werden.

Um auf Ihr Beispiel zu erweitern:

%Vor%

Sie sollten err aus dem obigen Bereich an den Callback übergeben, nicht an die Funktion, mit der Sie gerade arbeiten (im obigen Fall callback ). Der einzige Grund, diese Funktionen zu benennen, ist das Debugging.

Der Grund, warum sie nicht zu throw err sagen, ist, weil der Knoten Fehler-zuerst-Rückrufe verwendet. Jeder erwartet von Ihrer Bibliothek, wenn sie Rückrufe verwendet, ihre Fehler als ersten Parameter für den Rückruf zu propagieren. Zum Beispiel:

%Vor%     
royhowie 30.05.2015 02:53
quelle