You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR adds initial support for handling custom errors with Typechain.
Still WIP but opening a draft PR to be able to get input from others on the approach (currently heavily inspired on #457).
The idea here is to be able to handle errors in js/ts more cleanly when interacting with the chain.
Although the functionality isn't here yet, it would be cool to be able to use these to have cleaner try catches when doing interactions with ethersjs
The current setup returns "undefined" for the error objects but is inspired in this. A couple alternatives on how this could work (ie could rely on ethers and upstream something there or could just have a separate entrypoint). That said, I think only the typed error object exports themselves are already useful, could also have a utility function to get the signature / encode expected values
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
This looks reasonable. I am personally not a huge fan of custom errors and furthermore, ethersjs support is kinda minimal but the PR looks good!
@krzkaczor out of interest - what's the reasoning for not being a fan of custom errors? It feels like they provide a better opportunity to handle errors in clients, and can also reduce bytecode in deployed contracts. But i'm interested in any downsides too before using in a project
This would be an awesome improvement for typechain and the web3 developer experience overall IMO. Really looking forward to see this one merged. Would also be interested in arguments against it, @krzkaczor.
Would love to see this merged, will unblock an issue with hardhat not having access to the errors in the interface provided by typechain and therefore not being able to use assertion helpers such as revertedWithCustomError in the chain helpers plugin they provide.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds initial support for handling custom errors with Typechain.
Still WIP but opening a draft PR to be able to get input from others on the approach (currently heavily inspired on #457).
The idea here is to be able to handle errors in js/ts more cleanly when interacting with the chain.
Although the functionality isn't here yet, it would be cool to be able to use these to have cleaner try catches when doing interactions with ethersjs
The current setup returns "undefined" for the error objects but is inspired in this. A couple alternatives on how this could work (ie could rely on ethers and upstream something there or could just have a separate entrypoint). That said, I think only the typed error object exports themselves are already useful, could also have a utility function to get the signature / encode expected values