
Just a warning, unless a topic is personal, I’m going to start mostly writing on the JasperFx Software website to try to drive more traffic there.
Don’t throw exceptions for an entity that isn’t found or a value out of range — fair. But swapping that for Result<T> everywhere just trades one kind of noise for another: wrappers, .Match() calls, discriminated unions in every layer.
With Wolverine, most endpoints skip both:
- [Entity(Required = true)] → your 404
- FluentValidation → a 400 ProblemDetails
- Endpoint stays clean, and the OpenAPI metadata still comes out right — no .Produces() calls, no IResult “mystery meat,” no fake C# discriminator union ugliness
Exceptions still earn their place for real failures — Wolverine turns those into retries, re-queues, and dead-lettering. But error handling shouldn’t be your control flow, and neither should a Result wrapper with idiomatic Wolverine usage.
Less ceremony, less noise. Full write-up with code in the comments 👇
Result Pattern or Exceptions for Errors? Wolverine Lets You Say “Neither”
Very nice, Wolverine keeps getting better!
Regarding the 400 `ProblemDetails` – is it possible to change the 400 to 422 for validation errors?
Not today, but that would be an easy pull request. 400 or 404 today. Now I’ve got to go look up what 422 even means…
Hehe, it’s “Unprocessable Content” (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/422). I’ve used status 422 for validation errors for several years, to distinguish between “validation errors” and “real errors”.
You learn something new every day. That’s an easy PR if you wanna do that.