The classification is probably right, but this post feels half-baked. There are some valuable points in here (never suppress exceptions that indicate programming errors!) but it's missing guidance on how to handle cases like bad user input, and how to actually do the exception handling for cases like file not found.

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.

Throwing exceptions in out-of-memory cases or something similar has no sense, since no real program can handle such exceptions properly. Throwing exceptions in cases of logic errors (like accessing an array with invalid index) has no sense, since they just conceal bugs. In other cases it's unclear what is exceptional and what is not. So why not just using normal control flow? That's why I personally use no exceptions (I program mostly in C++ and Rust).