Graydon Hoare wrote:
> - 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.
Let's say I have a function parse_file(), it might fail because of I/O
problems or syntax failures, or it may give me back a valid parsed
object. Given that both errors may be detected at any depth in the
internal call tree, in another language exceptions would be a good
approach, keeping the success path apart from the failure path.
With the approach above, this means using a task to contain the
failure, i.e. the model is spawn/wait, rather than try/catch.
(Tasks are again taking a role like a language construct, not merely
as a scheduling entity.)
Jim
--
Jim Peters (_)/=\~/_(_) j...@uazu.net
(_) /=\ ~/_ (_)
Uazú (_) /=\ ~/_ (_) http://
in Peru (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
