Removing errors package

[themantre]

The errors package is intended for defining code specific to each error. However, there are a few issues with this approach:

• It is not feasible to define code for every possible error.
• The errors package becomes burdened with knowledge about all errors, which is considered an anti-pattern.

A more effective approach would be to define errors within their respective packages and ensure they are decoupled from one another.

The following packages will need to be updated to define errors locally:

• types/account
• types/block
• types/certificate
• types/proposal
• types/tx
• types/validator
• types/vote
• consensus
• committee
• crypto
• execution
• network
• sandbox
• sortition
• state
• store
• sync
• txpool
• wallet

Proposed Changes:

1- Define errors directly in each package where they are used.
2- Update error handling and tests in each package to refer to the errors defined locally rather than in utils/errors.
3- Consider creating a <package>/errors.go file that exports any errors that need to be shared across multiple packages. But each package still owns its own errors.

This change will make error handling cleaner and tests more self-contained by defining errors alongside the code that uses them. It removes unnecessary coupling between packages introduced by centralizing errors.

Once all errors have been converted, we can close this issue.

[b00f]

This post describes the conventional way to define errors in Golang: https://travix.io/errors-derived-from-constants-in-go-fda6748b4072