Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

error handling for add_message_in #2

Closed
ggutoski opened this issue Jan 5, 2021 · 1 comment
Closed

error handling for add_message_in #2

ggutoski opened this issue Jan 5, 2021 · 1 comment
Assignees
@ggutoski
Labels
enhancement New feature or request

Comments

@ggutoski
Copy link
Contributor

ggutoski commented Jan 5, 2021

Currently State::add_message_in() has no return value and panics on any error. We need to properly handle errors. Errors can be one of two types:

  1. Party error. (eg. failure to deserialize.) A party has done something bad. This kicks the protocol into fault attribution mode. No error should be returned in this case.
  2. Caller error. (eg. repeated message.) No party has done something bad, so don't kick the protocol into fault attribution mode. The caller must have screwed something up. In this case, either return an error or panic.

Originally posted by @sergeynog in #1 (comment)
@ggutoski ggutoski self-assigned this Jan 5, 2021
@ggutoski ggutoski added the enhancement New feature or request label Jan 5, 2021
@ggutoski ggutoski mentioned this issue Jan 5, 2021
Merged
@ggutoski
Copy link
Contributor Author

Folding this issue into axelarnetwork/tofnd#1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ggutoski ggutoski

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ggutoski