Wie werden Fehler mit IcedCoffeeScript korrekt behandelt?

Ich löse dieses Problem durch Stil- und Codierungskonventionen. Und es kommt die ganze Zeit auf. Lassen Sie uns Ihren Schnipsel unten, ein wenig mehr ausgearbeitet, damit wir eine funktionierende Funktion haben.

Du hast genau recht, das ist hässlich, weil du an vielen Stellen aus dem Code kommutierst, und du musst daran denken, jedes Mal, wenn du zurückkommst, c anzurufen.

Die anderen Snippets, die Sie ausgegeben haben, liefern falsche Ergebnisse, da sie Parallelität einführen, wenn eine Serialisierung erforderlich ist.

Meine persönlichen ICS-Codierungskonventionen sind: (1) Nur einmal von einer Funktion zurückkehren (welche Kontrolle fällt vom Ende ab); und (2) versuchen, Fehler auf der gleichen Ebene des Einrückens zu behandeln. Umschreiben, was Sie haben, in meinem bevorzugten Stil:

Im Falle eines Fehlers beim Aufruf von socket.get müssen Sie den Fehler zweimal überprüfen, und es wird offensichtlich beide Male fehlschlagen. Ich glaube nicht, dass dies das Ende der Welt ist, da es den Code sauberer macht.

Alternativ können Sie dies tun:

Wenn Sie autocb verwenden, was nicht meine Lieblings-ICS-Funktion ist, wird der Compiler den autocb für Sie aufrufen, wenn Sie die Funktion verlassen / kurzschließen. Ich finde diese Konstruktion aufgrund der Erfahrung fehleranfälliger. Stellen Sie sich zum Beispiel vor, Sie müssten zu Beginn der Funktion eine Sperre erfassen, jetzt müssen Sie sie n-mal freigeben. Andere stimmen vielleicht nicht überein.

Eine andere Anmerkung, auf die unten in den Kommentaren hingewiesen wird. autocb funktioniert wie return , da nur ein Wert akzeptiert wird. Wenn Sie wie in diesem Beispiel mehrere Werte zurückgeben möchten, müssen Sie ein Array oder ein Wörterbuch zurückgeben. defer macht Destrukturierungsaufgaben, um Ihnen hier zu helfen:

Wie bereits in Issue # 35 des IcedCoffeeScript-Repository beschrieben, gibt es eine andere Technik, die auf dem Eisted-Stil basiert connectors , bei denen es sich um Funktionen handelt, die einen Callback / Deferral als Eingabe nehmen und einen anderen Callback / Deferral zurückgeben.

Stellen Sie sich vor, Ihr Projekt hat eine Standardreihenfolge von Argumenten für Rückrufe: Der erste Parameter ist immer der Fehler, der bei Erfolg Null ist. Nehmen Sie außerdem an, dass Sie eine Funktion bei der ersten Fehlermeldung hinterlassen möchten.

Der erste Schritt besteht darin, einen Connector zu erstellen, den ich "ErrorShortCircuiter" oder "ESC" nenne:

Was wie folgt implementiert ist:

Um zu sehen, was das tut, betrachten Sie ein Beispiel, wie man es benutzt:

Diese Version von my_fn erstellt zuerst einen ErrorShortCircuiter (oder esc ), dessen Job zweifach ist: (1) fire gcb mit dem error-Objekt; und (2) protokollieren Sie eine Nachricht darüber, wo der Fehler aufgetreten ist und was der Fehler war. Natürlich sollten Sie das genaue Verhalten basierend auf Ihrer Einstellung variieren. Dann erhalten alle nachfolgenden Aufrufe von Bibliotheksfunktionen mit Rückrufen Callbacks, die wie üblich von defer generiert werden, und dann durch den Connector esc , der das Verhalten des Rückrufs ändert. Das neue Verhalten besteht darin, die Funktion gcb global für die Funktion bei einem Fehler aufzurufen und den aktuellen await -Block bei Erfolg zu beenden. Auch im Erfolgsfall muss man sich nicht mit einem Null-Fehler-Objekt befassen, daher werden nur die nachfolgenden Slots (wie id , image und permitted ) ausgefüllt.

Diese Technik ist sehr mächtig und anpassbar. Die Schlüsselidee ist, dass die von defer generierten Callbacks wirklich Fortsetzungen sind und den nachfolgenden Kontrollfluss des gesamten Programms verändern können. Und sie können dies in einer Bibliothek tun, so dass Sie das Fehlerverhalten erhalten, das Sie für viele verschiedene Arten von Anwendungen benötigen, die Bibliotheken mit unterschiedlichen Konventionen aufrufen.