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).

> Don’t catch fatal exceptions; nothing you can do about them anyway, and trying to generally makes it worse.

Yes there is something: you can design an exception handling system which lets your code specify choices about what to do if such an exception occurs within its contour. Those choices provide ways of passing control to that code.

Then the next layers above the code can decide whether to take those choices, or some other similar choices available from eslewhere, or let the exception bubble up, possibly leaving it unhandled.

The article is a decent tutorial for working with Blub exceptions, but it's limited to that.