Socket.io Fehlerweitergabe Konventionen

Question

Hintergrund: In Node, ist es üblich, Anrufe in Error handling in Node.js durch Joyent sowie erläutert einen Fehler Objekt zu einer Callback-Funktion in async passieren. Ein Standardfehlerobjekt enthält einen Namen, eine Nachricht, einen Stack-Trace und mögliche zusätzliche Eigenschaften. Das Übergeben oder Werfen von Strings oder einfachen Objekten als Fehler wird als schlechte Übung betrachtet. Mit Socket.io können Daten von Client zu Server und umgekehrt übertragen werden, indem Ereignisse ausgelöst werden und ein optionaler Rückmeldungsrückruf erfolgt. Dies eröffnet mehrere Möglichkeiten zum Übergeben und Behandeln von Fehlern.

Frage: Wenn ein socket.io-Ereignis von einem Client einen Fehler auf dem Server verursacht, was ist die beste Vorgehensweise, um den Client darüber zu informieren? Ein einfaches Fehlerobjekt als Antwort? Ein separates Fehlerereignis und Listener? Wie sollte der Fehler strukturiert sein? Gibt es Best Practices wie bei Node? Was benutzt du?

Beispiel: Stellen Sie sich socket.io für die Anmeldung vor. Ein Client meldet sich durch einen Benutzernamen und ein Passwort wie unten emittierende:

socket.emit('login', {user: 'Foo', pass: 'Bar'}, function (response) { 
    ... 
}); 

Auf einer erfolgreichen Anmeldung wird die Antwort enthält eine Session-Token. Was aber, wenn der Benutzername oder das Passwort nicht übereinstimmen? Mehrere Ansätze in dem Sinne kommen:

Ansatz 1 - Ebene Fehlerobjekt: Die Antwort eine Eigenschaft error mit einem einfachen Fehler artiges Objekt als Wert, mit Standardnamen und Nachrichteneigenschaften und möglichen zusätzlich diejenigen enthalten könnte:

{ 
    error: { 
    name: 'InvalidUsernameOrPasswordError', 
    message: 'Username or password was invalid.', 
    usernameExists: false 
    } 
} 

der Kunde somit prüft, ob Reaktion einen Fehler enthält und wenn nicht, setzt sich mit der Login-Prozedur:

socket.emit('login', {user: 'Foo', pass: 'Bar'}, function (response) { 
    if (response.hasOwnProperty('error')) { 
    // handle error 
    } 
    // do something with response.token 
}); 

Appro ach 2 - einfache Zeichenfolge: Ähnlich wie Ansatz 1, aber die Eigenschaft error ist nur eine einfache Zeichenfolge, die den Namen des Fehlers darstellt.

{ 
    error: 'InvalidUsernameOrPasswordError' 
} 

Dieser Ansatz ist leicht und ausreichend in diesem naiven Beispiel, aber es fehlt die Fähigkeit, zusätzliche Daten über den Fehler zu übergeben.

Ansatz 3 - separate Veranstaltung: Der Server hören emittieren und der Kunde konnte zusätzliche Ereignisse mögliche Ergebnisse zu handhaben:

socket.on('loginError', function (error) { 
    // handle error based on error.name and error.message 
}); 
socket.on('loginSuccess', function (data) { 
    // handle successful login with data.token 
}); 
socket.emit('login', {user: 'Foo', pass: 'Bar'}); 

Dieser Ansatz fühlt sich die deutlichste und rein unter dem Ereignisse Paradigma emittiert, erfordert jedoch mehr Ereignishandler.

Schlussfolgerungen: Es scheint viele Möglichkeiten zu geben, Fehler zu übergeben und zu behandeln. Irgendwelche Erfahrungen, Gedanken oder Gefühle?

Answer 1

Es hängt von Ihren "Kunden" ab. Wenn Sie Endbenutzer wie Leute haben, die eine Anwendung verwenden, ist es ihnen wirklich egal, wie Sie den Fehler senden. Am Ende wirst du einen Text auf dem Frontend haben, der sagt, dass sie falsch liegen. Sie sind also derjenige, der auswählen muss, wie Sie die Fehlerbehandlung im Backend implementieren möchten.

Wenn Ihre Clients keine Endbenutzer sind, wie im obigen Fall, erstellen Sie beim Imaging eine Anwendung oder Bibliothek, und Sie müssen sagen, dass ein Fehler aufgetreten ist. Sie sollten so viele Informationen wie möglich zurückgeben, damit Benutzer, die Ihre Anwendung verwenden, feststellen können, wo der Fehler liegt.

So am Ende:

-Für Kunden: Sie werden Ihre Fehler auf dem Frontend zeigen, so dass ups an Ihnen, wie Sie den Fehler verwalten möchten. -Für Entwickler: Sie sollten so viele Fehlerinformationen anzeigen, wie Sie können. Zeigt die Stack-Trace, Fehlercode ...