wasefire icon indicating copy to clipboard operation
wasefire copied to clipboard

Introduce Failure type for scheduler replies

Open lukeyeh opened this issue 1 year ago • 1 comments

This PR adds the Failure type to partially address #463.

  • The following PR will change SchedulerCall::reply() to take a Result<_, Failure> and fix any compilation errors.
  • The following PR after that will improve the try blocks that need to juggle to return an Error.

lukeyeh avatar May 11 '24 00:05 lukeyeh

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.

lukeyeh avatar May 11 '24 17:05 lukeyeh

Addressed comments and applied changes to equivalent areas that you didn't leave comments PTAL

lukeyeh avatar May 21 '24 19:05 lukeyeh

went through the new pass of comments with the new pattern and other various nits

lukeyeh avatar May 22 '24 17:05 lukeyeh