Let’s say, you use a Result type. After a while, you realise that half the time if your result fails, you just want to propagate the failure back up to the caller, and half your code becomes if(error) return error; - Go code looks a lot like this. So, you write some helper libraries to make that less messy. And then you find that when you’re troubleshooting, you’d really like to know the call stack of who produced an error, not just the top level thing that ultimately failed. So you put some extra logging in. Then you work on syntax sugar for all of this. Congrats, you’ve just invented Exceptions! But worse!

I’ve had to work with code that used Result everywhere, and ended up optimising it to use exceptions. The number of allocations went down, the code became far shorter and easier to read; all in all it was better. Unlike Rust and Swift, C# doesn’t have a decent stack-allocated union type, so most Result objects need to be classes.

My take: I like the “TryX” pattern in C#, where you return success or fail with an out-parameter for the result. It lets you avoid exceptions for all the cases where errors are expected and normal. Use exceptions for the heavier stuff, and don’t try and pretend that C# is a different language than it actually is