UNPREDICTABLE_GAS_LIMIT and gasEstimate()

[challet]

In the abstract class Signer, the function populateTransaction calls estimateGas if no gasLimit has been passed along the transaction.

Two scenarios with the same expected result could then be used :

• call estimateGas and pass the result to populateTransaction (that's what @wagmi/core prepareWriteContrat does for instance)
• call populateTransaction directly and let it make the estimate

In case of a revert in the contract method while eventually making the same low-level eth_estimateGas operation, these two scenarios throw different errors.

• calling estimateGas directly lets the error to bubbles up
• calling populateTransaction without gasLimit catches it and rethrows it as UNPREDICTABLE_GAS_LIMIT error

ethers.js/packages/abstract-signer/src.ts/index.ts

Lines 295 to 306 in 01aea70

	if (tx.gasLimit == null) {
	tx.gasLimit = this.estimateGas(tx).catch((error) => {
	if (forwardErrors.indexOf(error.code) >= 0) {
	throw error;
	}
	return logger.throwError("cannot estimate gas; transaction may fail or may require manual gas limit", Logger.errors.UNPREDICTABLE_GAS_LIMIT, {
	error: error,
	tx: tx
	});
	});
	}

Imho, the custom UNPREDICTABLE_GAS_LIMIT error should be thrown from inside estimateGas making it the same and then catchable for the both scenarios.

I'm also wondering about other providers and/or signers : is this behavior commonly enforced ? Do the thrown errors follow a common pattern and structure ?

[ricmoo]

Making bread types of changes in v5 could break backwards compatibility.

But have you tried v6 yet? In v6, they both throw a CALL_EXCEPTION, but the action property indicated estimateGas was the culprit. In both of the above cases. :)

[challet]

I haven't tried yet, will have a look. Nice to see there that each error type will have its own interface !