wasefire
wasefire copied to clipboard
Introduce Failure type for scheduler replies
This PR adds the Failure type to partially address #463.
- The following PR will change
SchedulerCall::reply()to take aResult<_, Failure>and fix any compilation errors. - The following PR after that will improve the try blocks that need to juggle to return an
Error.
Sorry, I probably used a misleading title in #463. This PR is not fixing the core idea of #463 but just introducing an unused private type, which is not useful on its own. Instead, for this PR to fix #463, it should:
* Introduce the `Failure` type and its 2 implementations at top-level (the enabler). * Change the `SchedulerCall::reply()` function to take a `Result<_, Failure>` instead (the actual change). * Fix any compilation error when calling `reply()` (the consequences). * Improve the try-blocks that currently have to juggle to return an `Error` (the benefit). This juggling can probably be identified by explicit use of `Ok` and `Err` within or right after the try-block .
I mainly wanted to add tests because I wanted to have this PR just add the failure type and following PRs to change ScheduelrCall::reply's signature and improve the try blocks. I didn't want to have to add a #[allow(dead_code)] marker, so added some tests. I moved the Trap and Failure back to lib.rs and left a TODO instead.
Addressed comments and applied changes to equivalent areas that you didn't leave comments PTAL
went through the new pass of comments with the new pattern and other various nits