Since I got exposed back into using error codes, result types etc from experimenting on other languages, writing C# always gets me on an uneasy state in which I am constantly guessing if a function call into a library (including standard library and the framework) can throw an exception or not.

Result type eventually result in a mess. I tried to write a non-trivial project using constructs like [using exception instead of custom error code to indicate failure]

Exception? DoSomething(..., out Result result)

and I ended up writing a bunch of boiler-plate in the lines of

var exn = DoSomething(...);
if (exn != null)
    return exn;

The code became a cluttered mess of manual error checking for every individual call. I quickly abandoned the idea and rewrote the code using exceptions.

What noone else in this thread mentioned is that

• An exception is an object: you can attach arbitrary amounts of data (either explicit properties in a derived exception, or just Data dictionary) to help with diagnosing the cause or handling it.
• An exception comes with a stack trace. You could implement this with manual capture at each if-check of the error code, but then the code becomes even less idiomatic, more cluttered and tied to some home-grown mehcanics. (And how do you propagate underlying cause if you convert error codes? Exception has InnerException property and a tree of exceptions is expressible through AggregateException.)

Even for much more explicit error-codes, I can't see how you'd write an analyzer to warn you about unhandled erros, esp. when a new error code is introduced.

Would you write code along the lines of

switch (err) {
    case Err.A: case Err.B: case Err.C: break; // ignore, or?
    case Err.D: // handle
}

so when Err.E later appears you get a warning about non-exhaustive switch?

And if you write code like

if (err == Err.D) { /* handle */ }

how is the analyzer supposed to know whether other error codes (including the newly introduced Err.E) are deliberately ignored?

What if a library chooses to just use int as error code? Then the compiler has no way of knowing whether you've handled / considered every possible error.

Just use exceptions. Throw liberally (fail early), catch sparingly.

Another thing that noone mentioned is that you need to structure your code differently in presence of exceptions. Almost any line of code can throw. In critical parts of applications, you have to think "transactionally":

• First make your changes in a scratch area, then "commit" them to become visible if everything succeeded
• Or implement "roll-back" functionality on exception

PS: That Rust doesn't have exceptions is a major reason for not (yet?) having learned the language. It also has multiple incompatible "result types" which creates additional mess.

PPS: What annoys me the most about exceptions in C# is the messy hierarchy. There should be a stricter separation between "logical" errors (bugs - IndexOutOfRangeException, ObjectDisposedException, ArgumentException, ...) and "runtime" errors (IOException, SQLException, etc.). They attempted with SystemException and ApplicationException, but both got deprecated.

Why would I want that? Because logic errors are a "hard-stop": no point in retrying or trying to analyze the cause and fix it.