[neonsunset]

Some of the details in the linked SO post are 15 years old(!).

Performance today is a very different story :)

With that said, exceptions are still very expensive and cost about 6-7us in .NET 8 and 3-4us in upcoming .NET 9. The cost will grow if the catch/catch with filter/multiple finally blocks are present and need to be executed up the call stack.

When it comes to I/O, the cost of "file no found" exception will be minuscule comparing to reaching to OS I/O stack. Luckily, many codebases today adopt one of the community packages to expose potentially failing operations with Result<T, E> instead. For some reason, the highest adoption is in the line-of-business code. Lower-level codebases often just do just Try* or T? patterns instead.

[gary_0]

> 6-7us in .NET 8 and 3-4us in upcoming .NET 9

That's still roughly 7000-3000 times slower than a plain return. I'm not convinced the extra overhead of an entirely separate control flow mechanism will ever be worth it in any language that cares about performance. Especially since I haven't heard many complaints about the way Rust does things. And there's still room for new idioms, syntactic sugar, and tweaks to the type system to optimize the convenience/rigor of that model.

> When it comes to I/O, the cost of "file no found" ...

That was just an example. Maybe that code is just a read from a (cached in memory) sqlite db, or a "value out of a range" error before some math operation, in which case the exception can easily be the most expensive part, especially if all the exception junk dirties up the CPU cache and branch predictor.

> Some of the details in the linked SO post are 15 years old(!).

Sigh. Thanks for the correction. You'd think I would have a habit of checking the post date by now!

[neonsunset]

> That's still roughly 7000-3000 times slower than a plain return. I'm not convinced the extra overhead of an entirely separate control flow mechanism will ever be worth it in any language that cares about performance. Especially since I haven't heard many complaints about the way Rust does things.

Ah, I did not mean to make a case for or against exception-based error handling. Only that it's not as expensive anymore, and that other operations do not necessarily use it: int.TryParse, dict.TryGetValue, encoding.TryGetBytes, etc.

I think the way Rust does it with Result<T, E> and, most importantly, implicit returns is the error handling perfected. You can criticize the language for being on the more verbose side, especially if you are not writing an OS kernel or a driver, but in terms of error handling while preserving the richness of error state it is by far the best per LOC.

One thing to note is, as usual, the Rust style error handling is not free either and you end up paying with at least a single branch in a happy path for each call that may error out provided it's not inlined and error check is not optimized away, and the additional codegen that is needed for blocks that e.g. construct a particular error and return, something that exception handling does "outside" of regular executed code (yes, with disproportionately higher cost but still).