rand_core and error types

[dhardy]

If we are to make this crate independent of rand_core, then we need to include an error type here.

We could simply copy the one rand_core uses; I think something simpler and equivalent on no_std may be preferable however. A quick look at the code shows that where we do include a cause, we are mostly just using an integer error code. Whether it is even worth forwarding the cause is another question.

[newpavlov]

I would prefer to use a simple (non-exhaustive) error enum without any associated explicit error codes.

[dhardy]

If we can translate the source error codes appropriately, that's probably the best option.

[dhardy]

I just reviewed the error handling — mostly I like it.

Would it be sensible to use common high-part for the two error constants?

It would be nice to have some ErrorKind enum (generated on-request from the error code, including common system-specific codes), but that can be added later.

Looking at Rand's ErrorKind, two get special handling:

• Transient causes retry soon-ish; possibly we should trap io::ErrorKind::Interrupted and retry a few times?
• NotReady allows detection of blocking, which isn't relevant to the current code here (I don't see much need to add this option, but we still could add it later if necessary, perhaps via fn is_ready()).

[newpavlov]

possibly we should trap io::ErrorKind::Interrupted and retry a few times?

Hm, I think we better to do it in the rand_os wrapper instead and keep getrandom as thin as possible.

It would be nice to have some ErrorKind enum

I think conversion into io::Error mostly covers the need for an additional ErrorKind.

[dhardy]

We already do repeat-on-error for RDRAND.

I think conversion into io::Error mostly covers the need for an additional ErrorKind.

Excepting that we have a couple of custom error codes.

[newpavlov]

We already do repeat-on-error for RDRAND.

We follow Intel recommendations here (see section 5.2.1), IIRC in tight loop approximately each 2nd-4th execution of rdrand returns an "error", so I think it's different from Interrupted error.

[dhardy]

I think retry-on-interrupt is applicable to all users as with RDRAND? The difference is importance; it may be that interrupt errors are rare enough that no one would notice?

keep getrandom as thin as possible.

I still plan to discuss using RDRAND as a backup option. That's another discussion, but if we did do so would have some impact here.

[dhardy]

Using NonZeroU32 in the Error type implies a requirement on rustc ≥ 1.28. Once we port Rand to use this, that requirement would be implied there too. Do we want this?

Alternatively we could just use u32; would we lose much? Likely Result<(), Error> would be larger due to the missed non-zero optimisation. Is this worth it? (In the longer term, possibly so?)

[dhardy]

The WASM implementations in #10 left a few errors poorly handled (marked TODO): two cases with a static string description and two cases with a stdweb::web::error::Error type (which is apparently a reference to a JS value).

Being able to forward an error would be nice but is not essential. Safely forwarding another error requires either a tagged enum over all possible sources or an allocator, as I understand it; neither are ideal.

So what is the best option? Can a single type be sufficient for both std and no_std uses?

And can we design a better solution for rand_core and use the same type there? Should we just use the existing rand_core type here?

Perhaps the best option is to keep the current type but map each error classification to a specific constant.

[newpavlov]

Perhaps the best option is to keep the current type but map each error classification to a specific constant.

I prefer this option. I think we can document error codes in the getrandom documentation and then map those codes to rand_core::Error in rand_os.

[dhardy]

How do you think we should deal with forwarded errors then?

use stdweb::web::error::Error as WebError;

        let err: WebError = js!{ return @{ result }.error }.try_into().unwrap();
        Err(UNAVAILABLE_ERROR)  // TODO: forward err

The only useful methods this type gives us come from the Debug, Display and std::error::Error implementations. I don't want to start matching against display strings, so then we can't do anything useful here.

Should we use log to print a warning?