Ich fange an, über eine angemessene Ausnahmebehandlung in meiner Django-App nachzudenken, und mein Ziel ist es, es so benutzerfreundlich wie möglich zu machen. Aus Gründen der Benutzerfreundlichkeit möchte ich darauf hinweisen, dass der Benutzer immer eine detaillierte Erklärung darüber erhalten muss, was genau falsch gelaufen ist. Im Anschluss an diesen Beitrag empfehlen wir
Verwenden Sie eine JSON-Antwort mit dem Status 200 für Ihre normalen Antworten und geben Sie eine (passende!) 4xx / 5xx-Antwort für Fehler zurück. Diese können tragen JSON-Nutzdaten, so dass Ihre Serverseite zusätzliche Details hinzufügen kann über den Fehler.
Ich habe versucht, nach den Schlüsselwörtern in dieser Antwort zu googlen, indem ich immer noch mehr Fragen als Antworten in meinem Kopf habe.
Betrachten wir es in einer einfachen Ansicht
%Vor%Zuerst sollten Sie überlegen, welche Fehler Sie anzeigen möchten:
In der Regel werden 4xx-Fehler (Fehler, die der Client-Seite zugeordnet sind) gemeldet, damit der Benutzer die Anfrage korrigieren kann.
Auf der anderen Seite werden 5xx-Fehler (Fehler, die der Serverseite zugeschrieben werden) normalerweise nur ohne Informationen dargestellt. Meiner Meinung nach sollten Sie Tools wie Sentry verwenden, um diese Fehler zu überwachen und zu beheben, bei denen möglicherweise Sicherheitsprobleme auftreten.
Da dies meiner Meinung nach eine korrekte Ajax-Anfrage ist, sollten Sie einen Statuscode und dann ein JSON zurückgeben, um zu verstehen, was passiert ist, wie eine Nachricht und eine Erklärung (falls zutreffend).
Wenn Ihr Ziel es ist, Ajax zu verwenden, um Informationen zu übermitteln, schlage ich vor, ein Formular für das zu erstellen, was Sie tun wollen. Auf diese Weise können Sie den Validierungsprozess problemlos durchlaufen. Ich nehme an, der Fall ist dies in dem Beispiel.
Erste - Ist die Anfrage korrekt?
%Vor%Zweite - Gibt es Fehler im Formular?
%Vor%Sie können sogar Fehler Feld für Feld erhalten, so dass Sie besser im Formular selbst dargestellt werden können.
Third - Lassen Sie uns die Anfrage bearbeiten
%Vor% Abhängig von den von Ihnen definierten Ausnahmen können verschiedene Codes erforderlich sein. Gehe zu Wikipedia und überprüfe die Liste.
Vergessen Sie nicht, dass die Antwort auch im Code variiert. Wenn Sie etwas zur Datenbank hinzufügen, sollten Sie ein 201 zurückgeben. Wenn Sie gerade Informationen erhalten haben, haben Sie nach einer GET-Anfrage gesucht.
Beantworten der Fragen
Django-Exceptions werden 500 Fehler zurückgeben, wenn sie nicht behandelt werden, denn wenn Sie nicht wissen, dass eine Ausnahme passieren wird, dann ist es ein Fehler auf dem Server. Mit Ausnahme von 404 und Login Anforderungen würde ich try catch Blöcke für alles machen. (Für 404 kannst du es erhöhen und wenn du @login_required oder eine Erlaubnis benötigst, wird django mit dem entsprechenden Code antworten, ohne dass du irgendetwas tust).
Ich stimme dem Ansatz nicht vollständig zu. Wie Sie sagten, sollten Fehler explizit sein, so dass Sie immer wissen sollten, was passieren soll und wie Sie es erklären und es von der durchgeführten Operation abhängig machen können.
Ich würde sagen, dass ein Fehler von 400 in Ordnung ist. Es ist eine schlechte Anfrage, die Sie nur erklären müssen, warum, der Fehlercode ist für Sie und für Ihren js-Code, also seien Sie nur konsequent.
(Beispiel bereitgestellt) - In der text_view sollten Sie die test_method wie im dritten Beispiel haben.
Die Testmethode sollte die folgende Struktur haben:
%Vor%Das in meinem Beispiel:
%Vor%Ich betrachtete den Geschäftslogik-Verstoß als einen Client-Fehler, da der Client, wenn etwas vor dieser Anfrage benötigt wird, dies beachten und den Benutzer bitten sollte, dies zuerst zu tun. (Aus der Fehlerdefinition ):
Der Statuscode 400 (Bad Request) zeigt an, dass der Server nicht oder verarbeitet die Anfrage nicht aufgrund von etwas, das als wahrgenommen gilt ein Client-Fehler (z. B. ungültige Syntax der Anfrage, ungültige Anfrage
Nachrichtenrahmen oder irreführendes Anforderungs-Routing).
Sehen Sie sich übrigens die Python-Dokumente für benutzerdefinierte Ausnahmen an kann entsprechende Fehlermeldungen geben. Die Idee hinter diesem Beispiel ist, dass Sie eine BusinessLogicViolation -Ausnahme mit einer anderen Nachricht in my_business_logic_is_violated() entsprechend dem Ort, an dem sie generiert wurde, auslösen.
Die Statuscodes sind im HTTP-Standard sehr gut definiert. Sie können eine sehr gut lesbare Liste auf Wikipedia finden. Grundsätzlich sind die Fehler im 4XX-Bereich Fehler, die vom Client gemacht werden, d. H. Wenn sie eine Ressource anfordern, die nicht existiert, usw. Die Fehler im 5XX-Bereich sollten zurückgegeben werden, wenn serverseitig ein Fehler auftritt.
Was Punkt 3 betrifft, sollten Sie einen 4XX-Fehler für den Fall auswählen, dass eine Vorbedingung nicht erfüllt ist, z. B. 428 Precondition Required , aber einen 5XX-Fehler zurückgeben, wenn ein Server einen Syntaxfehler verursacht.
Eines der Probleme mit Ihrem Beispiel besteht darin, dass keine Antwort zurückgegeben wird, außer der Server löst eine bestimmte Ausnahme aus, d. h. wenn der Code normal ausgeführt wird und keine Ausnahme ausgelöst wird, werden weder die Nachricht noch der Statuscode explizit an den Client gesendet. Dies kann mit einem finally-Block erledigt werden, um diesen Teil des Codes so generisch wie möglich zu machen.
Wie in Ihrem Beispiel:
%Vor%Wie jedoch in den Kommentaren erwähnt, wäre es sinnvoller, beide Validierungen auf die gleiche Art und Weise durchzuführen, d. h. über Ausnahmen wie:
%Vor%