Error handling in Rand is a compromise between simplicity and necessity. Most RNGs and sampling functions will never produce errors, and making these able to handle errors would add significant overhead (to code complexity and ergonomics of usage at least, and potentially also performance, depending on the approach). However, external RNGs can fail, and being able to handle this is important.
It has therefore been decided that most methods should not return a
Result type, but with a few important exceptions, namely:
Most functions consuming random values will not attempt any error handling, and
reduce to calls to
RngCore's "infallible" methods. Since most RNGs cannot
fail anyway this is usually not a problem, but the few generators which can may
be forced to fail in this case:
OsRngis a wrapper over
getrandom. From the latter's documentation: "In general, on supported platforms, failure is highly unlikely, though not impossible."
OsRngwill forward errors through
RngCore::try_fill_byteswhile other methods panic on error.
thread_rngseeds itself via
OsRngon first use and periodically thereafter, thus can potentially fail, though unlikely. If initial seeding fails, a panic will result. If a failure happens during reseeding (less likely) then the RNG continues without reseeding; a log message (warning) is emitted if logging is enabled.