Especially true as API design seems to have moved away from using exceptions in non-exceptional situations; handling them locally is not desirable in most cases

Especially true as API design seems to have moved away from using exceptions in non-exceptional situations; handling them locally is not desirable in most cases. In the old days we'd have a Parse method that would blow up the program if your string had characters other than digits; now we have a TryParse that returns e.g. an option type. It could also be because of the industry I'm in, but I've written (and read) extremely little exception-handling code in the last few years, because a real exception is not something my little domain method can do anything about. That said, exception handling syntax is ugly and cumbersome in most languages I've seen. Whether it's try/catch/finally with braces or begin/rescue/ensure/end or whatever. It's also rarely written in a way that tells the reader where exactly the exceptions come from, it's just a blanket for a large block of code. Something that ties the handling directly to the statement that breaks, without the noise of including the 'exceptional' behavior alongside the main logic, might be an improvement: result = do_something(x, y, z) handle SomeArgumentError with my_nre_handler(x, y, z) handle RecordNotFound with missing_record_handler(x)