I've found that it's hard to instill in teams, "exceptions shouldn't be for user errors."
Perhaps it's an artifact of C#, exceptions are built into the language and sufficient user error handling mechanisms are not. You get some `Try*()` methods but often don't have as much error information as you'd like.
You can mimic Rust's `Result` pattern in C# without much trouble and I've found that to be a good way to go. The biggest downside is the lack of namespace-level typedefs so you always have to include that TError parameter. It's a small price to pay.
I agree with the classification of TA, but I disagree on the "vexing exceptions". Even if you get a `Result` that you can pattern match over, the error handling code looks exactly as ugly if you put it into a pattern match branch as inside of a `catch` block.
I slightly disagree. I think two things are better with the result type:
1. Exception overhead. Exceptions capture diagnostics and unwind stacks in ways that add cost to the user-error case.
2. Type system information. With the result type, you declare the possibility to fail, and exactly what failures to expect in normal operation. You can switch over specific errors vs the broad category of anything that inherits from `Exception`
Perhaps it's an artifact of C#, exceptions are built into the language and sufficient user error handling mechanisms are not. You get some `Try*()` methods but often don't have as much error information as you'd like.
You can mimic Rust's `Result` pattern in C# without much trouble and I've found that to be a good way to go. The biggest downside is the lack of namespace-level typedefs so you always have to include that TError parameter. It's a small price to pay.