If they're important enough to be part of the language, somebody's going to use them... and common library functions will too. Exceptions aren't usually somethi

If they're important enough to be part of the language, somebody's going to use them... and common library functions will too. Exceptions aren't usually something you can boycott in a language ... and if you're going to have to use them, well, it's best to treat them as part of your program's logic, yes? Consider the many different errors Google handles and it's not always a dead failure... https://github.com/google/lmctfy/blob/master/util/task/codes.proto https://github.com/google/lmctfy/blob/master/util/task/codes... it's nice to be able to both return a value and an unambiguous exception state with automatic closure of resources (e.g. finally, or rewinding the stack...) such that you can safely retry without cleaning up after yourself. That's the goal here. Of course, Google's Go language avoids exceptions by using multiple return values, conventions and a defer statement... but then you can't easily put all your error handling code in any one place, can you, without restructuring your code? To each language its conventions, I suppose.