The current APIs are designed to only be fallible where failure is expected and recoverable at runtime -- e.g. when querying whether an algorithm is supported, or a key is loaded that fails some checks.
There has been some discussion on whether that is the right choice for all situations; in particular, a hardware accelerator connected via some bus might simply report a bus error.
The current approach is to treat those like irrecoverable hardware errors (just like a memory access fault due to a bad RAM cell would result in a crash) after which no sensible device operation is possible, and turn such failures into panics, rather than lugging around an error state that most implementations do not even inhabit. (Granted, those most implementations could use the Infallible type there).
I still think that that is the right path, but it should be documented -- and if there's any reason to change something about it, this issue is a good place to make any point about it.
The current APIs are designed to only be fallible where failure is expected and recoverable at runtime -- e.g. when querying whether an algorithm is supported, or a key is loaded that fails some checks.
There has been some discussion on whether that is the right choice for all situations; in particular, a hardware accelerator connected via some bus might simply report a bus error.
The current approach is to treat those like irrecoverable hardware errors (just like a memory access fault due to a bad RAM cell would result in a crash) after which no sensible device operation is possible, and turn such failures into panics, rather than lugging around an error state that most implementations do not even inhabit. (Granted, those most implementations could use the
Infallibletype there).I still think that that is the right path, but it should be documented -- and if there's any reason to change something about it, this issue is a good place to make any point about it.