Skip to content

NU6 Audit: Suggestion 2: Improve Error Handling and Avoid Using Panics #8904

Open

Description

Motivation

There are a number of instances where the code could potentially panic, leading to the code crashing unexpectedly. For example, If any of the parameters in parameters/network/subsidy.rs are not correctly set, then this will lead to panics in all of the below functions

  • block/subsidy/general.rs#L106
  • block/subsidy/general.rs#L137
  • src/block/check.rs#L189
  • subsidy/funding_streams/tests.rs#L132

This is just an example and there may be other instances where this could happen.

Scope

Least Authority recommends removing panics where possible. One of the possible improvements is to propagate errors to the caller and handle them on the upper layers. Note that error handling does not exclude using panics. In addition, if a caller can return an error, the callee function may not panic but, instead, propagate an error to the caller.

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

Metadata

Assignees

Labels

C-auditCategory: Issues arising from audit findingsI-panicZebra panics with an internal error messageNU-6Network Upgrade: NU6 specific tasks

Type

No type

Projects

  • Status

    Sprint Backlog

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions