Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

introduce errors with info #1834

Merged
merged 65 commits into from
Oct 27, 2020
Merged

introduce errors with info #1834

merged 65 commits into from
Oct 27, 2020

Conversation

drahnr
Copy link
Contributor

@drahnr drahnr commented Oct 21, 2020

As discussed with @bkchr we need debug info in errors and the rationale behind not including them (i.e. such as in ring) is not a rational decision given rust error handling and the scope of our implementation.

@drahnr drahnr self-assigned this Oct 21, 2020
@github-actions github-actions bot added the A3-in_progress Pull request is in progress. No review needed at this stage. label Oct 21, 2020
@drahnr drahnr force-pushed the bernhard-errors-with-info branch 2 times, most recently from 11b1664 to d374799 Compare October 21, 2020 12:01
@coriolinus
Copy link
Contributor

Any chance we could use snafu instead of thiserror? We don't want to just propagate errors; we want to add context most of the time, and ResultExt is very useful for that.

For example, in broadcast_signal, every subsystem will produce precisely the same error, so it would be very helpful to be able to annotate which subsystem's error actually got propagated.

@drahnr
Copy link
Contributor Author

drahnr commented Oct 21, 2020

My idea was to use thiserror for the subsystem error definition, but then use anyhow for the overseer, which also provides a fn context(..).

I never worked with snafu, thiserror is just usually a safe bet, given it boils down to something you would implement manually as well.

@drahnr
Copy link
Contributor Author

drahnr commented Oct 21, 2020

Any chance we could use snafu instead of thiserror? We don't want to just propagate errors; we want to add context most of the time, and ResultExt is very useful for that.

I think thiserror is not limited by that, it just boils down having to add another error variant with the same type of source error, the ergnomics are a bit different though.

For example, in broadcast_signal, every subsystem will produce precisely the same error, so it would be very helpful to be able to annotate which subsystem's error actually got propagated.

Since that would bubble up in the overseer, we would have annotations there. I just would prefer to very concretely and explcitily typed errors being passed around.

@coriolinus
Copy link
Contributor

coriolinus commented Oct 21, 2020

Yeah, I do also like thiserror; it just makes the question of adding the context a bit more tricky. We could, for example, add a variant to SubsystemError:

Contextualized(&'static str, Box<SubsystemError>),

and

impl SubsystemError {
  fn context(self, ctx: &'static str) -> Self {
    Self::Contextualized(ctx, Box::new(self))
  }
}

and then do .map_err(|err| err.into().context("whatever")) all over the place, but that's kind of awkward.

@drahnr drahnr added A2-insubstantial Pull request requires no code review (e.g., a sub-repository hash update). C1-low PR touches the given topic and has a low impact on builders. B0-silent Changes should not be mentioned in any release notes and removed A2-insubstantial Pull request requires no code review (e.g., a sub-repository hash update). C1-low PR touches the given topic and has a low impact on builders. labels Oct 21, 2020
@ordian
Copy link
Member

ordian commented Oct 21, 2020

Another error library option is https://github.com/yaahc/color-eyre which is developed by one the Error Handling Project Group's shepherds, see this video for more details.

@drahnr
Copy link
Contributor Author

drahnr commented Oct 21, 2020

Another error library option is https://github.com/yaahc/color-eyre which is developed by one the Error Handling Project Group's shepherds, see this video for more details.

Ah yes! I remember, there was a video from rust conf this year, but it's mostly an anyhow replacement rather than an thiserror replacement.

I think I have a rough idea and will go for thiserror with eyre for now, unless the pain becomes too large, but right now it looks fairly good.

@drahnr

This comment has been minimized.

@ordian
Copy link
Member

ordian commented Oct 26, 2020

@drahnr it seems after the CI update to latest nightly, you need to update Cargo.lock to include paritytech/substrate#7381 and maybe paritytech/substrate#7395

* master:
  Expose the backend from a full node (#1852)
  fix compilation on nightly (#1850)
@ordian
Copy link
Member

ordian commented Oct 26, 2020

bot merge

@ghost
Copy link

ghost commented Oct 26, 2020

Waiting for commit status.

@ghost
Copy link

ghost commented Oct 26, 2020

Checks failed; merge aborted.

@drahnr drahnr merged commit fec0e49 into master Oct 27, 2020
@drahnr drahnr deleted the bernhard-errors-with-info branch October 27, 2020 07:10
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants