On 6/1/12 2:59 AM, David Rajchenbach-Teller wrote:
The other problem is that the function may not have enough information
to determine what is "locally unrecoverable". I believe that `remove` is
a good example of issues whose recoverability depend on the context.
I'm not sure I understand what the problem is. It seems like it is easy
for `remove()` to recover and return a `result<>` type. The caller can
then elect to handle the error however it chooses.
A couple of potential problems I can see:
- if this is a recurse `remove()`, it may be possible to continue and
delete other files. This would seem like a good candidate for a
Graydon-style handler, so that `remove()` could invoke the handler with
the details of which file it failed to remove and why and the handler
can indicate whether `remove()` ought to continue.
- the caller can easily ignore the return value accidentally and thus
not be aware that return has failed. We probably ought to make it so
that ignored return values must be explicitly acknowledged, as in
O'caml, using the lint pass. I think this will prevent a lot of bugs in
general. Therefore, to call `remove()` without caring whether it
succeeds or fails you would write:
let _ = remove(...);
This would raise a red flag during code review, just as `try { remove();
} catch (Exception e) {}` ought to raise a red flag.
Are there other complications I have not considered?
Niko
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
