Better error reporting when interacting with undeployed contracts #4141
Comments
|
Another related use case - calling undeployed library functions. When library functions are declared as public or external, the library must be deployed separately and then linked before it can be used. |
|
I keep bumping into this issue every time I make a new deployment which I need to cross-reference in another repository - I forget to bump the block number. The error message is generic and difficult to reverse engineer: 
|
|
sg @PaulRBerg — agreed we could probably improve this error. Will take a stab at this during the next week to see if we can improve this |
|
I've bumped into the same situation again and spent ~15 minutes that would have been spared had Foundry detected that the contract doesn't exist on the network. cc @grandizzy I suspect this is a common debugging situation, especially when running tests against mainnet forks. |
Component
Forge
Describe the feature you would like
I have bumped into many
EvmErrorerrors that were caused by an attempt to interact with a contract which was either undeployed already or was deployed to a local network and by the time I was making the call, the contract did no longer exist because I had used a fork cheatcode.I think that this is such a common scenario that it would be extremely helpful (and prevent many angry reports in the Foundry Support group) for Foundry to handle this sort of error more gracefully and display a clearer error, e.g.:
The text was updated successfully, but these errors were encountered: