-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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.
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
feat: add FuelError
package and related utilities
#1153
feat: add FuelError
package and related utilities
#1153
Conversation
Coverage report
Show new covered files 🐣
Show files with reduced coverage 🔻
Test suite run success1178 tests passing in 204 suites. Report generated by 🧪jest coverage report action from b5b1c70 |
* Adding extra Generic type for greater flexibility * Removing Jest extension * Adding utility helper * Improving readability * Re-configuring errors package; adding new `test-utils` entrypoint * Begin to standardize `packages/address` errors * Adding missing tests * Fixing version range for workspace dependency * Lintfix * Updating lockfile * Tyop * Removing lost import * Lintfix
…rdize-error-handling-inside-of-the-sdk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a few more notes.
There's also a (unused import) lint issue in:
packages/address/src/utils.ts
FuelError
as a starting point towards error standardizationFuelError
package and related tooling
@nedsalk We could have a read-only I know you want to avoid standardizing error handling for more packages in this PR, but it's essential that we have subsequent (per-package?) PRs addressing this. I created an issue to track this: |
FuelError
package and related toolingFuelError
package and related utilities
…rdize-error-handling-inside-of-the-sdk
…rdize-error-handling-inside-of-the-sdk
…rdize-error-handling-inside-of-the-sdk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clean 👏🏻
Please make sure to file a follow-up issue for the logger issue you mentioned in the PR description, and maybe an epic issue for the conversion of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, small change and can approve
Co-authored-by: Daniel Bate <djbate23@gmail.com>
I've opened up an issue for the logger: #1207. |
This PR adds a new
errors
package based off of #1110.Thanks @arboleya for your contributions!
An additional question remains: what should we do with the usage of
@ethersproject/logger
for throwing errors? Currently, throwing errors is done in two ways inside of the SDK, either viathrow new Error...
orlogger.throw...
. I've tried writing examples in theabi-coder
package, but this ambiguity stopped me. @arboleya added examples inaddress
package where he substitutedlogger
withFuelError
as a showcase, but we should still have a discussion because we're using the logger alongside ourversions
and currentlyFuelError
doesn't have any version info in it.This PR is mergable as-is, regardless of how we deal with the logger issue, as anything logger-related can be built on top of it. After we resolve the logger issue, errors throughout the SDK can be standardized to use only one approach. We can still reference this package in any subsequent PRs whenever we see someone of us throwing a new error directly and just say "Hey, can you think of a properly-named error code and use
FuelError
instead ofError
?"Note that updating the errors throughout the
fuels-ts
packages is outside of the scope of this PR, as that isn't a small endeavor because careful thought needs to be put into error code naming. Also, sometimes the actual code implementation where an error is thrown might not 100% reflect the error code being used, which might necessitate some refactoring to have it make more sense.Closes #1110.