nicht angemeldet
Tach!
Warum es da in Express nicht möglich sein soll, ein solches Interface nicht in einen try Block setzen zu können, wird wohl immer Euer Geheimnis bleiben. Daß das FW asynchron arbeitet reicht mir als Erklärung jedenfalls nicht 😉
Das ist ein generelles Problem bei asynchronem Code, nicht spezifisch für Express.
In Express gibt es ein Request- und ein Responseobjekt in JEDER Methode. Wenn der Code mit der Response fertig ist, geht es daran die Response auszugeben. Und die geht IMMER in Richtung Client, egal ob der Code bis dahin asynchron oder sysnchron durchlaufen wurde. D.h., genau hier hat man die Möglichkeit, das Responseobjekt zu befragen ob es bis dahin Fehler gegeben hat.
Ja, natürlich können Fehler auch in asynchronen Programmteilen abgefangen werden, aber nicht mit try/catch. Das war der Punkt deiner Aussage, der nicht stimmte: das try/catch, nicht das Behandeln generell. Der Unterschied ist nicht die prinzipielle Vorgehensweise sondern die konkrete. Die muss für asynchron laufenden Programmteile geeignet sein und kein try-catch-Block.
Zwischen "Funktion wird aufgerufen, weil der Router einen Request an sie gibt" und "Response wird abgeliefert" kann durchaus noch der eine oder andere asynchrone Aufruf stecken, beispielsweise Datenbankabfragen, die das Ergebnis asynchron ermitteln und bereitstellen.
Der Fehler kann also nicht vom nicht mehr existenten try-catch-Scope gefangen werden. Wenn man den Fehler fangen möchte, muss man einen try-catch-Block in den Callback schreiben.
Den try braucht man da wo Fehler auftreten können. Und da ist immer auch das Responseobjekt was mit den dazugehörigen Texten gefüttert werden kann.
Nein, das Response-Objekt steht nicht immer zur Verfügung. Ein Service, der benötigte Daten aus einer Datenhaltung holt, muss vom Response-Objekt nichts wissen. Das ist nicht seine Aufgabe, sich um die Response zu kümmern. Der soll nur die Daten holen. Sehr wohl können dabei aber Fehler auftreten. Nur kann er die nicht mit einem throw zurückwerfen, weil aufgrund seiner asynchronen Arbeitweise der Fehler vom Aufrufer nicht mit try/catch gefangen werden kann. Stattdessen bedient man sich eines Mechanismus der Promises, mit denen solche Asynchronitäten heutzutage gern abgehandelt werden. Beim Aufrufen eines Promises übergibt man nicht nur einen Callback für das Ergebnis im Gutfall, sondern auch noch einen weiteren, der im Fehlerfall aufgerufen wird. In diesen beiden Callbacks kann man dann das Response-Objekt auf die eine oder andere Weise befüllen. Also, wenn man im Request-Handler ist, ansonsten ruft man die error-Funktion des Promises auf, um den Fehler an den Aufrufer weiterzugeben.
dedlfix.