Future of types/errors package and sdk-wide errors

[julienrbrt]

Summary

With the introduction of cosmossdk.io/errors, there are two errors packages in the SDK:

• cosmossdk.io/errors
• types/errors

The documentation says to use cosmossdk.io/errors for new code and deprecates the old package functions.
However, types/errors is still a list of SDK-wide errors used by many modules, and it is not clear when these errors-wide errors should be used instead of modules defined errors.

Proposal

We should eventually remove the deprecated logic from types/errors and possibly the package entirely over the next few versions.

I have tried a quick clean of the codebase to reflect that: #12182 where the types/errors package stays a list of SDK errors but does not contain any other logic, namely is just errorstypes.

As mentioned in #12182 (comment) we should investigate if and which errors can be moved to the errors package and to an internal errors package.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[tac0turtle]

so the reason we shouldn't migrate the errors is because if a package or app chain has an error they should define there own with a appCodeSpace in order to better distinguish with sdk errors and their own. We should document this design choice for the app chain developers.

Yes, some errors will need to be duplicated, but it has the the potential to bring in better debug-ability for users