It not just kept the translations in the Mermaid diagram (as told) but also updated/fixed them and removed a line of code which was gone in the English diagram.
And fixed/updated many other things. Not one unnecessary change.
# Abhängigkeiten mit `yield` { #dependencies-with-yield }
FastAPI unterstützt Abhängigkeiten, die nach Abschluss einige <abbrtitle="Manchmal auch genannt „Exit Code“, „Cleanup Code“, „Teardown Code“, „Closing Code“, „Kontext Manager Exit Code“, usw.">zusätzliche Schritte ausführen</abbr>.
@ -23,7 +23,7 @@ Tatsächlich verwendet FastAPI diese beiden Dekoratoren intern.
///
## Eine Datenbank-Abhängigkeit mit `yield`.
## Eine Datenbank-Abhängigkeit mit `yield` { #a-database-dependency-with-yield }
Sie könnten damit beispielsweise eine Datenbanksession erstellen und diese nach Abschluss schließen.
@ -35,7 +35,7 @@ Der ge`yield`ete Wert ist das, was in *Pfadoperationen* und andere Abhängigkeit
@ -47,7 +47,7 @@ Sie können `async`hrone oder reguläre Funktionen verwenden.
///
## Eine Abhängigkeit mit `yield` und `try`.
## Eine Abhängigkeit mit `yield` und `try` { #a-dependency-with-yield-and-try }
Wenn Sie einen `try`-Block in einer Abhängigkeit mit `yield` verwenden, empfangen Sie alle Exceptions, die bei Verwendung der Abhängigkeit geworfen wurden.
@ -59,7 +59,7 @@ Auf die gleiche Weise können Sie `finally` verwenden, um sicherzustellen, dass
## Unterabhängigkeiten mit `yield` { #sub-dependencies-with-yield }
Sie können Unterabhängigkeiten und „Bäume“ von Unterabhängigkeiten beliebiger Größe und Form haben, und einige oder alle davon können `yield` verwenden.
@ -93,7 +93,7 @@ Dieses funktioniert dank Pythons <a href="https://docs.python.org/3/library/cont
///
## Abhängigkeiten mit `yield` und `HTTPException`.
## Abhängigkeiten mit `yield` und `HTTPException` { #dependencies-with-yield-and-httpexception }
Sie haben gesehen, dass Ihre Abhängigkeiten `yield` verwenden können und `try`-Blöcke haben können, die Exceptions abfangen.
@ -109,9 +109,27 @@ Aber es ist für Sie da, wenn Sie es brauchen. 🤓
Eine Alternative zum Abfangen von Exceptions (und möglicherweise auch zum Auslösen einer weiteren `HTTPException`) besteht darin, einen [benutzerdefinierten Exceptionhandler](../handling-errors.md#benutzerdefinierte-exceptionhandler-definieren){.internal-link target=_blank} zu erstellen.
Eine Alternative zum Abfangen von Exceptions (und möglicherweise auch zum Auslösen einer weiteren `HTTPException`) besteht darin, einen [benutzerdefinierten Exceptionhandler](../handling-errors.md#install-custom-exception-handlers){.internal-link target=_blank} zu erstellen.
## Ausführung von Abhängigkeiten mit `yield`
## Abhängigkeiten mit `yield` und `except` { #dependencies-with-yield-and-except }
Wenn Sie eine Exception mit `except` in einer Abhängigkeit mit `yield` abfangen und sie nicht erneut auslösen (oder eine neue Exception auslösen), kann FastAPI nicht feststellen, dass es eine Exception gab, genau so wie es bei normalem Python der Fall wäre:
In diesem Fall sieht der Client eine *HTTP 500 Internal Server Error*-Response, wie es sein sollte, da wir keine `HTTPException` oder Ähnliches auslösen, aber der Server hat **keine Logs** oder einen anderen Hinweis darauf, was der Fehler war. 😱
### In Abhängigkeiten mit `yield` und `except` immer `raise` verwenden { #always-raise-in-dependencies-with-yield-and-except }
Wenn Sie eine Exception in einer Abhängigkeit mit `yield` abfangen, sollten Sie – sofern Sie nicht eine andere `HTTPException` oder Ähnliches auslösen – die ursprüngliche Exception erneut auslösen.
Sie können dieselbe Exception mit `raise` erneut auslösen:
Jetzt erhält der Client dieselbe *HTTP 500 Internal Server Error*-Response, aber der Server enthält unseren benutzerdefinierten `InternalError` in den Logs. 😎
## Ausführung von Abhängigkeiten mit `yield` { #execution-of-dependencies-with-yield }
Die Ausführungsreihenfolge ähnelt mehr oder weniger dem folgenden Diagramm. Die Zeit verläuft von oben nach unten. Und jede Spalte ist einer der interagierenden oder Code-ausführenden Teilnehmer.
@ -135,22 +153,22 @@ participant tasks as Hintergrundtasks
opt Löst aus
operation -->> dep: Löst Exception aus (z. B. HTTPException)
opt Handhabt
dep -->> dep: Kann Exception abfangen, eine neue HTTPException auslösen, andere Exceptions auslösen
dep -->> handler: Leitet Exception automatisch weiter
dep -->> dep: Kann Exception abfangen, eine neue HTTPException auslösen, andere Exception auslösen
end
handler -->> client: HTTP-Error-Response
end
operation ->> client: Sendet Response an Client
Note over client,operation: Response wurde gesendet, kann nicht mehr geändert werden
Note over client,operation: Response wurde bereits gesendet, kann nicht mehr geändert werden
opt Tasks
operation -->> tasks: Sendet Hintergrundtasks
end
opt Löst andere Exception aus
tasks -->> tasks: Handhabt Exception im Hintergrundtask-Code
tasks -->> tasks: Handhabt Exceptions im Hintergrundtask-Code
end
```
/// info
/// info | Info
Es wird nur **eine Response** an den Client gesendet. Es kann eine Error-Response oder die Response der *Pfadoperation* sein.
@ -160,13 +178,13 @@ Nachdem eine dieser Responses gesendet wurde, kann keine weitere Response gesend
/// tip | Tipp
Obiges Diagramm verwendet `HTTPException`, aber Sie können auch jede andere Exception auslösen, die Sie in einer Abhängigkeit mit `yield` abfangen, oder mit einem [benutzerdefinierten Exceptionhandler](../handling-errors.md#benutzerdefinierte-exceptionhandler-definieren){.internal-link target=_blank} erstellt haben.
Obiges Diagramm verwendet `HTTPException`, aber Sie können auch jede andere Exception auslösen, die Sie in einer Abhängigkeit mit `yield` abfangen, oder mit einem [benutzerdefinierten Exceptionhandler](../handling-errors.md#install-custom-exception-handlers){.internal-link target=_blank} erstellt haben.
Wenn Sie eine Exception auslösen, wird diese mit yield an die Abhängigkeiten übergeben, einschließlich `HTTPException`, und dann **erneut** an die Exceptionhandler. Wenn es für diese Exception keinen Exceptionhandler gibt, wird sie von der internen Default-`ServerErrorMiddleware` gehandhabt, was einen HTTP-Statuscode 500 zurückgibt, um den Client darüber zu informieren, dass ein Fehler auf dem Server aufgetreten ist.
Wenn Sie eine Exception auslösen, wird sie an die Abhängigkeiten mit `yield` weitergegeben, einschließlich `HTTPException`. In den meisten Fällen sollten Sie dieselbe Exception oder eine neue aus der Abhängigkeit mit `yield` erneut auslösen, um sicherzustellen, dass sie korrekt gehandhabt wird.
///
## Abhängigkeiten mit `yield`, `HTTPException` und Hintergrundtasks
## Abhängigkeiten mit `yield`, `HTTPException`, `except` und Hintergrundtasks { #dependencies-with-yield-httpexception-except-and-background-tasks }
/// warning | Achtung
@ -176,7 +194,15 @@ Diese Details sind vor allem dann nützlich, wenn Sie eine Version von FastAPI v
///
Vor FastAPI 0.106.0 war das Auslösen von Exceptions nach `yield` nicht möglich, der Exit-Code in Abhängigkeiten mit `yield` wurde ausgeführt, *nachdem* die Response gesendet wurde, die [Exceptionhandler](../handling-errors.md#benutzerdefinierte-exceptionhandler-definieren){.internal-link target=_blank} wären also bereits ausgeführt worden.
### Abhängigkeiten mit `yield` und `except`, technische Details { #dependencies-with-yield-and-except-technical-details }
Vor FastAPI 0.110.0 war es so, dass wenn Sie eine Abhängigkeit mit `yield` verwendeten und dort eine Exception mit `except` abfingen und die Exception nicht erneut auslösten, diese Exception automatisch an Exceptionhandler oder den internen Serverfehler-Handler weitergereicht/ausgelöst wurde.
Dies wurde in Version 0.110.0 geändert, um unbehandelte Speichernutzung durch weitergereichte Exceptions ohne Handler (interne Serverfehler) zu beheben und um das Verhalten an regulären Python-Code anzugleichen.
### Hintergrundtasks und Abhängigkeiten mit `yield`, technische Details { #background-tasks-and-dependencies-with-yield-technical-details }
Vor FastAPI 0.106.0 war das Auslösen von Exceptions nach `yield` nicht möglich, der Exit-Code in Abhängigkeiten mit `yield` wurde ausgeführt, *nachdem* die Response gesendet wurde, die [Exceptionhandler](../handling-errors.md#install-custom-exception-handlers){.internal-link target=_blank} wären also bereits ausgeführt worden.
Dies wurde hauptsächlich so konzipiert, damit die gleichen Objekte, die durch Abhängigkeiten ge`yield`et werden, innerhalb von Hintergrundtasks verwendet werden können, da der Exit-Code ausgeführt wird, nachdem die Hintergrundtasks abgeschlossen sind.
@ -194,9 +220,9 @@ Wenn Sie sich früher auf dieses Verhalten verlassen haben, sollten Sie jetzt di
Anstatt beispielsweise dieselbe Datenbanksitzung zu verwenden, würden Sie eine neue Datenbanksitzung innerhalb des Hintergrundtasks erstellen und die Objekte mithilfe dieser neuen Sitzung aus der Datenbank abrufen. Und anstatt das Objekt aus der Datenbank als Parameter an die Hintergrundtask-Funktion zu übergeben, würden Sie die ID dieses Objekts übergeben und das Objekt dann innerhalb der Hintergrundtask-Funktion erneut laden.
## Kontextmanager
## Kontextmanager { #context-managers }
### Was sind „Kontextmanager“
### Was sind „Kontextmanager“ { #what-are-context-managers }
„Kontextmanager“ (Englisch „Context Manager“) sind bestimmte Python-Objekte, die Sie in einer `with`-Anweisung verwenden können.
@ -210,11 +236,11 @@ with open("./somefile.txt") as f:
Im Hintergrund erstellt das `open("./somefile.txt")` ein Objekt, das als „Kontextmanager“ bezeichnet wird.
Dieser stellt sicher dass, wenn der `with`-Block beendet ist, die Datei geschlossen wird, auch wenn Exceptions geworfen wurden.
Dieser stellt sicher, dass, wenn der `with`-Block beendet ist, die Datei geschlossen wird, auch wenn Exceptions geworfen wurden.
Wenn Sie eine Abhängigkeit mit `yield` erstellen, erstellt **FastAPI** dafür intern einen Kontextmanager und kombiniert ihn mit einigen anderen zugehörigen Tools.
### Kontextmanager in Abhängigkeiten mit `yield` verwenden
### Kontextmanager in Abhängigkeiten mit `yield` verwenden { #using-context-managers-in-dependencies-with-yield }