Better (more informative) error message when wrong network

Obviously it should be my responsibility as a developer to ensure smooth UI.

Libraries should help.

Rinkeby: all working fine.

Mainnet selected in Metamask:

ethers.umd.js:5701 Uncaught (in promise) Error: call revert exception (method="balanceOf(address)", errorSignature=null, errorArgs=[null], reason=null, code=CALL_EXCEPTION, version=abi/5.0.7)
    at Logger.makeError (ethers.umd.js:5701)
    at Logger.throwError (ethers.umd.js:5710)
    at Interface.decodeFunctionResult (ethers.umd.js:10638)
    at Contract.<anonymous> (ethers.umd.js:11737)
    at step (ethers.umd.js:11464)
    at Object.next (ethers.umd.js:11445)
    at fulfilled (ethers.umd.js:11436)

Took me some effort of debugging to figure it out.

Something that would help:

Ensure that the address exists, correct network yada yada

[zemse]

Given that extra rpc call adds costs due to the “pay per call” model of most providers, it is reasonable to not do this. When a dev actually gets the error during development, having a message similar to call reverted or contract is not deployed to this address/network would hint developer to look in to both of these possible cases. This would definitely reduce frustration (in my last company many of colleagues were stuck at exact this error multiple times)

[ricmoo]

@zemse there is actually a extcodehash too, which would be even cheaper, since then it only needs to lookup in the root state trie; code size still has to fetch the code to derive its size.

That said, it is only available after a certain hardfork and this would also mean storing another address in the code that may not exist on all networks; I can deploy it to rinkeby, mainnet, ropsten, etc. but then what of test networks people create locally or networks I’m unaware of or cannot acquire ether for.

I think it is something just linking to docs that says basically: “is your contract deployed? Sometimes build tools do not update artifact files correctly, please make sure the address is correct and for debugging try getCode to make sure your contract exists and the bytecode is present”.

Which reminds me of another common cause of this I will need to mention. Often people add a new method to a contract but the artifact fails to update the address (or the developers hard coded value isn’t updated, or have hardcoded the address multiple places and failed to update one), so they complain of call exceptions when the version of the contract is newer than the one they are actually calling (which is missing the new method)… I should include instructions on how to decompile bytecode and search for their method.

Basically, with Turing complete things there are a (countably) infinite number of thing that can go wrong. The best I can do is provide documentation on trying to diagnose them. 😃