In this post I discuss why you might want to use the result pattern, demonstrate it with a simple example and show a naïve, ugly, solution

Andrew Lock's blog focuses on ASP.NET Core development, web APIs, and software architecture. Readers can find tutorials, code samples, and explanations covering topics such as RESTful API design, authentication, and authorization in ASP.NET Core. Additionally, they can learn about dependency injection, middleware, and performance optimization techniques.

.NET Escapades

The post discusses the inefficiencies of using exceptions for flow control in .NET applications and introduces the result pattern as a more efficient alternative. It starts with a simple API implementation without error handling, adds exceptions for common error cases, and then replaces these exceptions with a Result<T> type to demonstrate the result pattern. However, the initial implementation of the result pattern is cumbersome, leading to the next post in the series where the pattern will be simplified further.

Replacing Exceptions-as-flow-control with the result pattern

Background: do we need another post about the result pattern?

The starting point: happy path handling only

<p>So everyone for 15 years was telling Go’s errors handling sucks, but now everyone is getting appreciate it :)</p>
