Result pattern or throwing exceptions? Wolverine says “neither”

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”

4 thoughts on “Result pattern or throwing exceptions? Wolverine says “neither”

  1. Very nice, Wolverine keeps getting better!

    Regarding the 400 `ProblemDetails` – is it possible to change the 400 to 422 for validation errors?

Leave a comment