try/catch does not work as expected with hardhat wallet addresses

[aathan]

In one of my tests, running against a hardhat forked chain I do:

   vm.prank(A);
   try token.transfer(B,x) { revert('should not have succeeded'); } catch { }

When A is one of the hardhat wallet addresses generated and printed out during npx hardhat node ..., it appears the call that is supposed to generate the revert() is certainly going out as STATICCALL. However, the try/catch does not catch the error and the test fails.

If I instead create a destination address by deploying a do-nothing contract and use its address, the try/catch works.

Does this sound like a hardhat issue that should be reported there instead?

[onbjerg]

I'll need a bit more context

• What is transfer doing? Why and how do you expect it to revert?
• Are you forking from Hardhat node?
• Do you deploy token in the test?
• Can you post a trace?

[aathan]

    ├─ [0] VM::prank(someWallet: [0xce71065d4017f316ec606fe4422e11eb2c47c246])
    │   └─ ← ()
    ├─ [4481] someToken (proxy)::transfer(account_A: [0x90f79bf6eb2c4f870365e785982e1f101e93b906], 100000000000000)
    │   ├─ [3453] someToken (implementation)::transfer(account_A: [0x90f79bf6eb2c4f870365e785982e1f101e93b906], 100000000000000) [delegatecall]
    │   │   ├─ [0] account_A::0902f1ac() [staticcall]
    │   │   │   └─ ← ()
    │   │   └─ ← ()
    │   └─ ← ()
    └─ ← ()
    ```

This is a private project and I cannot share very much. Above is the tail part of the trace. transfer() does a variety of checks and revert()'s the transaction in certain cases. Changing the address of account_A from a pre-defined hardhat address to a deployed "do nothing" contract address allows from a completely different outcome.

Also, yes, sorry I must have deleted that part of my original message accidentally, it's a hardhat fork. I "new" the contract (along with 10+ others) during the course of the test.

I'm aware that try/catch is only relevant for external calls and contract creations, but in this case nothing is different except the nature of what's at the pranking address.

[onbjerg]

You can't share the conditions of transfer?

Does it work if you use an address that is not a Hardhat address, e.g. vm.prank(address(100)) (note: you don't need to deploy anything)? Maybe the Hardhat Node is causing it on that specific address.

If this doesn't work, then it seems like one of your checks may directly or indirectly expect the sender to be a contract.

[aathan]

If I understand you correctly, you are reasoning that something in the condition is creating a panic vs an "Error"/revert?

When crunch time is finished over here I will try to build a reproducible example, but it should be that simple. I can't share large parts of the code no. Happy to share reasonable things :)

I did not think the conditions were relevant so I posted (under time crunch). A simple revert() statement in function transfer(...) and/or function transferFrom(...) should exhibit the problem. However, I understand your reasoning and it's possible, so lets wait to explore this further until I can more completely characterize the problem.

[aathan]

I think the issue may be related to this: ethereum/solidity#12725 ... but I'm not really sure. The behaviors just seem similar, in that error conditions may be thrown in unexpected ways relative to try/catch that may be in use to generate the trace??

[onbjerg]

We don't use try/catch to generate the trace. If try/catch doesn't work for you, then try the expectRevert cheatcode instead, which hooks into the EVM itself