Woah woah, I'm arriving late here.
We *have* exceptions. They're called 'failure'. The only point about
them is that you can't catch them. For a couple reasons:
- We can't re-establish task typestate from unknown starting point;
memory might not be initialized, arbitrary other predicates not
hold, etc.
- Philosophically, catching means either one of two things:
1. You know exactly what the failure means and an exact, transparent
recovery mode. For this we recommend simply modeling the recovery
mode you want for expected-but-rare circumstances as arguments
passed *into* the callee, and handled at the site of
circumstance. Think of how O_CREAT and O_TRUNC work in ::open.
We have these wonderful tag things for passing in such options,
they can be highly structured if necessary.
2. You don't or can't really understand and manage the failure,
want to wall off a whole subsystem, to contain an unknown failure
but otherwise, at best, just log it and try to reset/try again.
For this we have tasks and failure. Intentionally unrecoverable
until the task boundary, and intentionally not-very-typed.
IOW, our approach to managing faults requires thinking a bit and
classifying them, but not much more than you'd have to classify a java
exception as checked or unchecked. And we (hopefully) don't wind up
throwing or unwinding quite as much either, as a result.
Throwing (in terms of implementation) is actually not all that great:
it's a fair bit slower than just passing a flag, and catch paths in
production code are often bitrotted and/or untested. Flags for
common/expected special circumstances are much more likely to get
tested, run quickly and correctly.
There's a bit of fudging possible on that line because we've talked
about (and I'm still ok with) a cross-task failure notice being
something that carries an inspectable stack of "any" values (stacktrace
entries, "note"s, an original "fail" argument). But that's unimplemented
and, in any case, will never be precise: an "any" can always be some
type you weren't expecting.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
