Simplifying Error Handling with Monadic Approach

I have been involved in a legacy project that relies on XML files and a local database. My role is to modernize the system by transitioning it to leverage modern APIs and a centralized database for improved scalability and integration. While working on the new codebase, I encountered a challenge with managing error handling across multiple layers of processes. The project consists of several major processes, each composed of multiple sub-processes, and each sub-process can fail, resulting in an early return with an error message for the entire process.

To simplify error handling, I initially implemented the result pattern, which made the error management easier. However, as the number of sub-processes grew, I found myself writing repetitive conditional checks after each sub-process to verify whether the result was successful. This led to the code becoming less readable and more difficult to follow, with numerous if-conditions cluttering the logic.

Here’s an example of my previous approach:

As you can see, the method is composed of multiple steps, each requiring an error check. With more sub-processes, the method grows vertically, making it hard for anyone reading the code to understand the entire process at a glance.

To address this issue, I started researching ways to improve the readability and structure of the code. That’s when I came across the concept of monads and functional programming. By applying these principles, I was able to refactor my code to be much more concise and readable.

Here’s how the improved code looks:

Notice the difference? Now the code is more streamlined and easier to follow. The sequence of sub-processes is clear, and the handling of errors is simplified. It’s immediately apparent what steps are involved in the full process and how errors are managed.

How did I achieve this? The key was to ensure that all methods returned a unified MethodResult<T> type, which encapsulates the result, error messages, and additional details in three properties. I had been using this approach from the beginning to handle errors alongside the expected data, so there was no need to rewrite existing function signatures. By leveraging this common return type, I was able to chain functions together, allowing the output of one function to flow directly into the next. This monadic behavior enabled the entire process to be represented as a sequence of operations, with error handling integrated smoothly along the way.

To enable this, I created custom Bind(), Map(), and GetOrDefault() functions, which handle the chaining and error propagation: