In this series I provide a worked example of going from using exceptions for flow-control to using a result pattern to avoid throwing exceptions. The first post shows how the result pattern can remove a certain class of issues, but often introduces extra problems, namely an increase in boilerplate.

The second post in the series shows how we can use the extensible LINQ query syntax to dramatically reduce the boilerplate, giving easy-to-read methods, which nevertheless accurately describe their return values correctly (by not relying on exceptions) and handle errors in intermediate methods.

The third post builds on the second post, handling additional scenarios such as async methods, mixing methods that return Result<T> and simple T-returning methods, and handling collections of Result<T>. These scenarios are invariably required in practice, and this post describes the techniques and extension methods you can use to handle them.