Comment by mrsmrtss
2 months ago
The Result pattern also works exceptionally well with C#, provided you ensure that code returning a Result object never throws an exception. Of course, there are still some exceptional things that can throw, but this is essentially the same situation as dealing with Rust panics.
IMO, Rust panics should kill the application... C# errors shouldn't. Also, in practice, in C# where I was dealing with Result, there was just as much chance of seeing an actual thrown error, so you always had to deal with both an explicit error result AND thrown errors in practice... it was worse than just error patterns with type specific catch blocks.
I think you just had experienced a bad codebase. If you opt for using Result then you can not throw at the same time. If you follow this rule, then it works perfectly.
The problem is, the referenced libraries can (and do) throw in practice... which means your own code needs to account for this. Most libraries in C# are written to throw errors, which means interactions will mostly need to account for these at some level, which is a pain. Not to mention, Task<Result<T>> is awkward in and of itself, because a task result is a success or fail, wrapping another type that is a success or fail. And such is the nature of async + result in C@, which is kind of redundant. Which, again, depending on the libraries in use, you have to account for and it is and will get messy.
1 reply →
[dead]