I don't see how the Rust approach would avoid this fate but I doubt it will ever be used in these contexts to begin with.
First, you _have_ to do it, even if that means a try! and passing the buck. The syntax for this isn't as monstrous as it is for checked exceptions as well.
Second, it feels more like a natural code-flow, not the break that exceptions provide.
Third, it's useful for more than just "Exceptions". Coupled with Optional types, it provides a more expressive way of not-hapy-path-code where exceptions just feel heavy handed. For instance https://docs.python.org/3/library/stdtypes.html
d[key]
Return the item of d with key key. Raises a KeyError if key is not in the map.
In sum, I think the expressibility of Result and Option, along with a more natural flow for handling them will make working around them less tempting/viable/easy to pass over in a code review.
I think twenty-five years ago there were similar hopes and dreams for Java checked exceptions.
This is not a problem in Rust.
Yeaaaaaaah. I remember being a very strong supporter of checked exceptions before I got into a giant codebase and saw how not having speced a sane exception type can cause lots of pain and some really long declarations or dropped exceptions.
catch (Exception e) { throw new RuntimeError(e); }
You're right, I guess time will tell.
That said, dict also has get(), which lets you specify the default value if key wasn't found (and the default default is None).
No. They are usually logged. The difference is that with exceptions, the logging will occur at a higher level and be done uniformly while in Rust you'll have to explicitly thread the error through the call stack manually to log it at a higher level.
What about non-fatal errors such as retries in a GUI library that loads an image from the web, how are they logged or otherwise propogated to the developer?