Implicit error handling

[dhardy]

We currently have these error kinds (#9):

/// Permanent failure: likely not recoverable without user action.
Unavailable,
/// Temporary failure: recommended to retry a few times, but may also be
/// irrecoverable.
Transient,
/// Not ready yet: recommended to try again a little later.
NotReady,
/// Uncategorised error
Other,

next_u32 etc. and fill_bytes cannot report an error except via panic. Instead, these functions should probably:

• block if NotReady
• retry a few times if Transient

Additionally,

• all functions should implicitly retry on interrupt

---

There is some room for discussion here (especially how to handle Transient), but mostly this issue is to track implementation (PRs welcome).

[dhardy]

Specifically, see the impl of Rng for ReadRng and OsRng which both currently unwrap errors.

[burdges]

I think our lacking an associated error type will hamper error propagation in many situations where you'd actually care about the error. I asked a summary so far question to help document this and other compromises #29 but I'm kinda guessing there.

[dhardy]

@burdges (1) this point is about handling specific errors, not about propagating errors (#8 and #10 are more on topic for that), and (2) if we had an associated error type then we can have no generic handling (e.g. from_rng must either use fill_bytes for implicit error handling but panic, or try_fill_bytes to allow error propagation but do no implicit handling), so associated types make the situation worse.

[burdges]

It's worth glancing at the boats' new failure crate (via), but it fails no_std projects immediately so not ideal here.

[dhardy]

@burdges you're off topic in this issue for the second time. See also this comment; failure doesn't help much with this problem.

[dhardy]

#35 implements this for reseeding

[dhardy]

Note: interrupt handling is only required for std::io::Read; both implementations use read_exact which already retries on interrupt.

[dhardy]

It seems any implicit handling is being done locally (context-dependent), so no need for this issue.