Closed aljo242 closed 1 year ago
Merging #967 (513c88f) into develop (2345454) will increase coverage by
0.00%
. The diff coverage is69.86%
.
I thought as well, but then we're doing the same thing - sometimes importing errors from another package (our own now) and sometimes using errors we define in our types
package. Using the ignite errors also moves the codespace to some other spot (here "ignite") which isn't really giving any useful information. With this PR, every module only throws errors in its own codespace, or critical errors.
This is also more in line with the SDK design going forward, since they are deprecating those errors.
I thought as well, but then we're doing the same thing - sometimes importing errors from another package (our own now) and sometimes using errors we define in our types package. Using the ignite errors also moves the codespace to some other spot (here "ignite") which isn't really giving any useful information. With this PR, every module only throws errors in its own codespace, or critical errors.
This is also more in line with the SDK design going forward, since they are deprecating those errors.
Ok, this makes sense
What about completely removing https://github.com/ignite/modules/blob/main/pkg/errors/errors.go then? and do the same in modules
?
Remove all imports of
sdkerrortypes
from the repo. All usages are replaced by appropriate module-scoped error types. Some errors are repeated between modules, but scoping them to the modules, gives a bit more context. It also means that any clients or other code importing our code will just have to use our error types and no other 3rd party errors.