C# Wie gebe ich einen Status Code in einem MVC Controller mit spezifischem Typ zurück?

sandreas schrieb:
In vielen Sprachen gibt es gar keine Exceptions. Und du sagst damit, all diese Sprachen haben ein unsauberes Fehlermodell.
kann ich nicht beurteilen ich kenne die Sprache nicht, aber alle Sprachen die ich kenne, und das sind nicht wenig, haben Exceptions. Sogar JavaScript

für den größeren Block spar ich mir den Quote aber... das macht Sinn. ich hab nie drüber nachgedacht return und finally zu kombinieren. Und du hast Recht Exception Objekte sind ziemlich groß. Das ist zumindest ein gutes Argument. Vielleicht sollte ich doch nach alternativen für Exceptions gucken.

Allerdings sind wir ein bischen am Thema vorbei gedriftet denn ob ich Exceptions nehme oder nicht ändert nichts daran dass ich in einem streng typisierten Endpunkt keine Fehler-Datenmodelle zurückgeben kann ohne mit Exceptions und einer MiddleWare zu arbeiten.

Ich glaube auch mein Clean Code Argument kam falsch rüber. Ich meinte nicht "Clean Code" als Buchtitel. Ich bilde mir gerne selbst eine Meinung darüber was sauberer und guter Code ist, auch das ohne die Meinungen anderer zu überschreien, ich evaluiere was sie sagen selbst und überlege was für mich persönlich sinnvoller ist. Und denselben generischen Rückgabetyp für alle Funktionen zu verwenden nur um Fehlerdaten anzuhängen finde ich persönlich ziemlich dirty.

Ich versichere euch, ich werde all eure Meinungen und Aussagen im Hinterkopf behalten, ich lese sie gründlich durch und überlege ob sie für mich Sinn machen, allerdings verstehe ich auch wenn es durch meine Einstellung unangenehm ist. Das tut mir auch leid.

In jedem Fall habe ich nun viele Anregungen erhalten und ich werde sehen wie ich sie umwende, und die Diskussion über besseres Exception Handling werde ich wohl auch mal bei uns ansprechen. Danke für euer Feedback und eure Geduld :)
 
Ich hab es gerade nochmal ausprobiert, weil ich mir Recht sicher war das auch ActionResult<T> den Typ erkennt, und es macht das auch so wie VD90 es erklärt hatte hier. Der interessante Teil ist aber das das eben nur funktioniert wenn du ein reines Objekt hast das noch nicht in ein ActionResult verpackt wurde. Wenn du z.B. Ok() benutzt umgehst du den Typcheck.

Wenn du also nur explicit ActionResult für die Fehler benutzt mit StatusCode() und ansonsten deine eigentlichen Inhalte direkt zurückgibst, dann warnt dich der Compiler auch wenn es das falsche Objekt ist, und zwar beim Kompilieren schon. Du brauchst keine Middleware und Exceptions hier solange alle die daran entwickeln wissen das sie nicht unnötig Sachen in ActionResult verpacken sollen.
 
  • Gefällt mir
Reaktionen: Kokujou
what?! das ist ja genial! das hab ich... wirklich noch nirgends gelesen... darauf wär ich in tausend Jahren nicht gekommen. Das ist ja großartig! Dankeschön!
 
Ehm, ich hatte es schon vor ein paar Tagen geschrieben. Hat da etwa jemand die Posts nicht vollständig durchgelesen? :D

Wobei ich dann in Frage stellen würde, wieso überhaupt einen ActionResult zurückgeben, wenn die Vorteile davon nicht genutzt werden möchten… naja, jeder wie er soll - bei mir würde sowas aber niemals durch ne Review kommen.

Und doch, Swagger orientiert sich an dem Code, es wurde ziemlich verbessert. Es liest den generischen Typ des ActionResults und verwandelt diesen automatisch in API Dokumentation genau wie es die HTTPGet/Post/Put/... Attribute und die Funktionsparameter umwandelt. Ich muss z.B. in meinen Endpunkten gar keine Attribute verwenden, sogar dass ich JSON als standardformat verwende erkennt er automatisch durch das im Startup angegebene Plugin fürs MVC

Wie definierst du dann für dein Swagger-File die restlichen HTTP-Fälle, die der Endpoint potenziell liefert? Sprich, welchen Typen kann ich als Client bei einem 400er, 409er etc. erwarten? Deine Lösung klingt imo sehr unvollständig.
 
Zuletzt bearbeitet:
VD90 schrieb:
Wie definierst du dann für dein Swagger-File die restlichen HTTP-Fälle, die der Endpoint potenziell liefert? Sprich, welchen Typen kann ich als Client bei einem 400er, 409er etc. erwarten? Deine Lösung klingt imo sehr unvollständig.
Ist sie auch ich bin quasi mittendrin mir das alles irgendwie zusammenzuschustern. Erstmal ist NSwag geil weil es mir tausende von Code-Zeilens part. Automatisch generierte Clients, Models, sämtliche datenstrukturen eben. Um die Fehlerbehandlung kann ich mich kümmern wenn der Rest migriert ist.

Spontan würde ich aber sagen dass ich die Fehlertypen in einem selbstgeschriebenen HTTP Handler behandle, den ich sowieso angeben muss um so unseren auth header mitzuliefern.
 
Zurück
Oben