Skip to content
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

Better errors for un-configured ENS names #1066

Closed
zemse opened this issue Sep 24, 2020 · 5 comments
Closed

Better errors for un-configured ENS names #1066

zemse opened this issue Sep 24, 2020 · 5 comments
Labels
enhancement New feature or improvement. fixed/complete This Bug is fixed or Enhancement is complete and published.

Comments

@zemse
Copy link
Collaborator

zemse commented Sep 24, 2020

The documentation at https://docs.ethers.io/v5/api/providers/provider/#Provider--ens-methods mentions that:

In the ethers API, nearly anywhere that accepts an address, an ENS name may be used instead, which can simplify code and make reading and debugging much simpler.

Some examples I tried it on: new Contract(abi, address), provider.getBalance(address). And it works there, so awesome!

But when I did with a contract method:

> erc20ContractInstance.balanceOf('some.ens.name')

Error: invalid address (argument="address", value=null, code=INVALID_ARGUMENT, version=
address/5.0.2) (argument="_owner", value=null, code=INVALID_ARGUMENT, version=abi/5.0.2)

Is this expected?

Also seems like the value of address is being taken as null.

@ricmoo
Copy link
Member

ricmoo commented Sep 24, 2020

That should definitely work. I use it all the time. Is the ens name configured? If an ens name doesn’t have a resolver or an addr entry it will return null.

The library probably should throw, in theses cases, a better error than allow the address coder to start the error chain...

@ricmoo
Copy link
Member

ricmoo commented Sep 24, 2020

The only places an ens name cannot be used is when it is required synchronously. Like in utils.computeContractAddress and simile utility function. Anything that is async supports it. :)

@zemse
Copy link
Collaborator Author

zemse commented Sep 24, 2020

Thanks, I found out that I did not had the Networkish object passed for the particular provider that I had connected with the contract instance. So it was my mistake from my side. It is working now when done right.

Man, really, you have done such an amazing library! I'm so overwhelmed with this one. Actually I overrided the resolveName and lookupAddress methods to work with a different kind of registry (not similar to ENS). It's working smoothly even in this case!

The library probably should throw, in theses cases, a better error than allow the address coder to start the error chain...

That could be actually helpful. We can leave this issue open if in future this is desired to be addressed.

@ricmoo
Copy link
Member

ricmoo commented Sep 24, 2020

Yeah, a better error should only take like 4 minutes and I know exactly where to add it. :)

I just need to finish the new publish script to match the new build script and I’ll add this. Sure, open a new issue to track it. :)

Glad you enjoy the library! :)

@ricmoo ricmoo added the discussion Questions, feedback and general information. label Sep 24, 2020
@ricmoo ricmoo added enhancement New feature or improvement. on-deck This Enhancement or Bug is currently being worked on. and removed discussion Questions, feedback and general information. labels Sep 26, 2020
@ricmoo ricmoo changed the title Using ENS names as function parameters gives error Better errors for un-configured ENS names Sep 26, 2020
@ricmoo
Copy link
Member

ricmoo commented Oct 3, 2020

This has been published in 5.0.15. Try it out and let me know if there are any issues.

Thanks! :)

@ricmoo ricmoo added fixed/complete This Bug is fixed or Enhancement is complete and published. and removed on-deck This Enhancement or Bug is currently being worked on. labels Oct 3, 2020
@zemse zemse closed this as completed Oct 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement. fixed/complete This Bug is fixed or Enhancement is complete and published.
Projects
None yet
Development

No branches or pull requests

2 participants