Good topic, but I think you’re missing some of the very good things about exception mechanisms.
The common-path behaviors can be coded, read, and understood a whole lot more simply when a large class of program/environment states can be handled in a different part of the code. if you’ve ever written i/o code in C, you’ll stop thinking that exceptions don’t solve real problems.
Languages with general-purpose disjoint return types are way harder to use, and most often just get exception handling added as a library.
The vast majority of real-world code is multi-programmer, and clear communication of expectations and behaviors, even in unusual conditions, is not adversarial, it’s cooperative.
It’s important to note that exceptions do not necessarily indicate errors. It just indicates a change from normal-path assumptions. Testing for whether the internet is down or a disk is full with EVERY SINGLE function call that may or may not actually use it is … tiresome. Letting the actual library/syscall that does the thing fail in a visible way is just much smoother.
You can catch and handle the condition at any level you like. If you don’t want to react (or you know for certain that it’s not actually a problem), you can let it pass through. If you DO want to do something differently, catch it and handle it (and perhaps throw a new/chained exception if the catching function’s behavior is unexpected by YOUR caller).
I call it elegant to acknowledge and handle both common-path intended uses and uncommon-path situations where the code CAN’T behave as expected.
Good topic, but I think you’re missing some of the very good things about exception mechanisms.
The common-path behaviors can be coded, read, and understood a whole lot more simply when a large class of program/environment states can be handled in a different part of the code. if you’ve ever written i/o code in C, you’ll stop thinking that exceptions don’t solve real problems.
Languages with general-purpose disjoint return types are way harder to use, and most often just get exception handling added as a library.
The vast majority of real-world code is multi-programmer, and clear communication of expectations and behaviors, even in unusual conditions, is not adversarial, it’s cooperative.
It’s important to note that exceptions do not necessarily indicate errors. It just indicates a change from normal-path assumptions. Testing for whether the internet is down or a disk is full with EVERY SINGLE function call that may or may not actually use it is … tiresome. Letting the actual library/syscall that does the thing fail in a visible way is just much smoother.
You can catch and handle the condition at any level you like. If you don’t want to react (or you know for certain that it’s not actually a problem), you can let it pass through. If you DO want to do something differently, catch it and handle it (and perhaps throw a new/chained exception if the catching function’s behavior is unexpected by YOUR caller).
I call it elegant to acknowledge and handle both common-path intended uses and uncommon-path situations where the code CAN’T behave as expected.