On 6/2/12 6:06 PM, Niko Matsakis wrote: > 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.
I actually meant the functions called by the implementation of `remove`.
For instance, `copy` generally does not have to return anything
meaningful. So if we assume that it is locally recoverable, in this
design, it should return a `result<>` type – but chances are that users
will forget to pattern-match it, since they do not care about that
result. If we assume that it is generally irrecoverable, well, we have
to use a failure as an exception in the implementation of `remove`.
> 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(...);
Good point, I had not thought about that.
> This would raise a red flag during code review, just as `try { remove();
> } catch (Exception e) {}` ought to raise a red flag.
Do I understand correctly that you mean actual reviews and not
lint-style warnings?
Cheers,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
