Monads in C# (Part 2): Result

Post by veleon » Mon, Jan 05, 2026, 7:19 PM UTC

louthy wrote: post #60

naasking wrote: post #47

Good review, but I frankly don't see the point of Result . Just have the error be an exception type as exceptions idiomatically represents errors in .NET. Then you're down to only 1 type argument which is much less noisy. That's what I've used for the result type in my library that I've been using for years. I don't use it often, but it's very handy when appropriate.

If you ask yourself what the meaning of the word 'exception' is and then consider how many failures are exceptional , then one quickly realises that exceptions are the worst thing you could use to represent expected failure conditions. The only time we should throw (or even pass around) exceptions is if there isn't a slot in the co-domain to inject a value in to.

Post by louthy » Mon, Jan 05, 2026, 7:46 PM UTC

naasking wrote: post #61

louthy wrote: post #60

Earlier quoted context omitted.

If you ask yourself what the meaning of the word 'exception' is and then consider how many failures are exceptional , then one quickly realises that exceptions are the worst thing you could use to represent expected failure conditions. The only time we should throw (or even pass around) exceptions is if there isn't a slot in the co-domain to inject a value in to.

The dangers and pitfalls of exceptions are completely irrelevant if all you're doing is using an exception as a value and not for control flow.

Post by galkk » Tue, Jan 06, 2026, 3:23 AM UTC

moogly wrote: post #30

galkk wrote: post #5

Idk, to me that constant Result looks extremely ugly and unergonomic, even just to type. I understand that this is complicated topic and there were a lot of strong opinions even inside of Google about it, but god, I miss absl::StatusOr and ASSIGN_OR_RETURN. Yes, it won’t work without preprocessor magic (and that’s why this article goes through heavy functional stuff, otherwise it just cannot work in language like C#)…

Is this similar? https://github.com/amantinband/error-or What's some of the "preprocessor magic" that makes this[1] more ergonomic to use? [1]: https://github.com/abseil/abseil-cpp/blob/master/absl/status...

    absl::StatusOr loadUserById(int userId) { ... }

    absl::Status populateItems(User user, std::vector& items) {...}

    absl::StatusOr findItems(int userId) { 
        ASSIGN_OR_RETURN(auto user, loadUserById(userId));
        std::vector items;
        RETURN_IF_ERROR(populateItems(user, items));
        for (auto& item: items) {
        ...     
        }
   }

   absl::StatusOr findItems(int userId) { 
      auto userOrStatus = loadUserById(userId);
      if (!userOrStatus.ok()) return userOrStatus.status();
      auto user = *userOrStatus;
      std::vector items;
      absl::Status st2 = populateItems(user, items));
      if (!st2.ok()) return st2;
   }

Post by wvenable » Tue, Jan 06, 2026, 5:46 AM UTC

naasking wrote: post #49

xnorswap wrote: post #10

I really dislike this pattern: try { id = int.Parse(inputId); } catch (Exception ex) when (ex is FormatException or OverflowException) { throw new InvalidOperationException("DeactivateUser failed at: parse id", ex); } Where all you're doing when you catch an exception is throwing it in a more generic way. You could just let the FormatException or OverflowException bubble up, so the parent can handle those differently…

You're leaking implementation details if you let exceptions bubble. Sometimes this is ok if all of the callers are aware of the implementation details anyway, but it can make refactoring or changing implementations more difficult otherwise.

Post by naasking » Tue, Jan 06, 2026, 1:30 PM UTC

louthy wrote: post #64

naasking wrote: post #61

Earlier quoted context omitted.

The dangers and pitfalls of exceptions are completely irrelevant if all you're doing is using an exception as a value and not for control flow.

It’s not about danger it’s about being declarative. That’s kinda the point of using these ‘result’ types: you’re fully declaring the codomain of the function — barring exceptions — and so if your codomain is augmented with Exception then it’s pretty hard to know whether all exceptions will be returned in value form, or just exceptional exceptions! It’s fails the declarative test.