On 19/11/2011 4:14 AM, David Rajchenbach-Teller wrote:
I can't remember the title of the original exceptions paper, but if I recall correctly, exceptions were initially designed specifically to avoid such behaviors, as this quite often leads to messy and unreliable code.
Exceptions date back a long, long way. People have been batting this idea around since the 60s or earlier. I'd have to dig into the HOPL stuff on the shelf to find the origin, if it's even possible to locate.
What I want to point out here is this: if you study any of the deployed exception systems, and how they're used, you'll find they're still an active point of debate among language designers, some 50 years on. There's no approach that's clearly and unambiguously superior to others yet discovered. Nothing where people look at the resulting software and say "oh yes, it's orders of magnitude better at handling faults, or easier to reason about the faults in, than this other approach".
Oh, and a simple example where it does not work: you do not want to deal with scenario "user has suddenly removed the USB key" smack in the middle of your code for, say, serializing your data structure to a compressed output stream for said key. You want to do this at higher level.
No. That's a category #2 error. You moved the goalposts. Nobody involved in any of the libraries is able to predict that occurrence. It's an externally generated, byzantine fault. Those can happen anywhere and no API beyond "crash the subsystem and restart it" can sensibly defend against them. That's why we have "failure". Same as a divide-by-zero or whatever.
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
