search

webtech-uos / nodejs-lrs

node.js implementation of a learning record store (LRS) as described in the XAPI specifications
MIT License
9 stars 7 forks source link

StatementMapper: Fehlerwerte vereinheitlichen #34

Closed tthelen closed 10 years ago

tthelen commented 10 years ago

Es werden unterschiedliche Werte (Strings/Objekte) als Fehlerwerte verwendet. Besser wäre: einheitlich.

Jetzt:

TiloW commented 10 years ago

Am besten wäre es wahrscheinlich die Klasse Error für alle Fehler zu verwenden.

dlips commented 10 years ago

Ich habe noch eine Verständnisfrage dazu: Nach meinem Verständnis ist der Controller für die Kommunikation mit dem Client zuständig. Sprich für das Senden und Empfangen von Daten und weiterreichen an die Datenbank. Da kommt es mir irgendwie komisch vor, wenn in einem anderen Modul wie z.B. dem StatementMapper auf einmal entschieden wird, welcher HTTP Statuscode zurück gesendet werden soll. Ich fände es besser strukturiert wenn der StatementMapper nur die Art der Fehlers meldet. z.B. "Conflict" und der Controller dann entscheidet welcher Statuscode etc. gesendet wird. Korrigiert mich bitte wenn ich das falsch verstehe.

TiloW commented 10 years ago

Ja, da hast du schon recht. Die Entscheidung sollte auch im Controller fallen, der status code der vom Mapper geliefert wird soll also nur als Vorschlag verstanden werden. Wir können die Fehler auch explizit im Controller behandeln und eigene Fehlercodes für den Mapper definieren.

dlips commented 10 years ago

Ah ok. Ich fande es erst nur komisch das der Fehlercode im Controller einfach weitergereicht wird falls vorhanden. Aber das macht die Sache natürlich einfacher. Wenn man extra Fehlercodes für den Mapper hat, muss man ja immer zweimal nachschauen. Einmal was der Mapper Code bedeutet und einmal wie ich laut Spec. darauf reagieren soll. ich glaube das verschlimmbessert die Sache nur. Also Einwand zurückgezogen :)