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”

Leave a comment