Troubleshooting Contract Errors in Web3.js Transactions

Managing Errors Gracefully in React with Web3.js

When working with blockchain transactions in a React application utilizing Web3.js, it’s pivotal to handle errors effectively to ensure a smooth user experience. Recently, I encountered a challenging scenario where catching errors—such as when a user closes the wallet modal—proved tricky.

My app relies on transactions sent to a Solidity smart contract and requires real-time feedback for error handling. Despite the typical techniques such as try-catch, .then().catch(), and PromiEvents, catching the specific “User rejected the request.” error turned elusive. This blog post walks you through the issue, my attempts, and the ultimate solution that ensured robust error handling in my application.

The Original Challenge

Upon user interaction, where a modal prompted by their wallet (like MetaMask) was involved, closing this modal should ideally trigger error handling in my React application to alert the user accordingly. The aim was to catch any error, especially the “User rejected the request” when the modal was dismissed without approving the transaction.

Despite setting up several error-handling paradigms:

1. The try-catch block within an async function,

1. Chaining .then() with .catch() on the promise,

1. Listening to error events on a PromiEvent returned by the send() method.

None of these approaches caught the error as expected. Instead, the console threw an uncaught error which was not only misleading but also unhelpful for user experience.

Insights into the Error Handling Mechanisms

Initially, I employed a try-catch with an async function, hoping to capture any errors arising from the promise returned by the send() function:

try {
  const receipt = await factoryCampaignContract.methods
    .createCampaign(minimumContribution)
    .send({ from: accounts[0] });
} catch (err) {
  console.error('Transaction Error:', err);
}

However, this block didn’t catch the error when the user closed the modal. One plausible reason could be a deeper, uncaught promise within the Web3.js library or the Ethereum provider (like MetaMask).

With .then().catch(), the structure did not seem to differ much in functionality compared to try-catch in catching the said error:

factoryCampaignContract.methods
  .createCampaign(minimumContribution)
  .send({ from: accounts[0] })
  .then(receipt => console.log('Transaction Successful:', receipt))
  .catch(err => console.error('Transaction Error:', err));

The Breakthrough with PromiEvents

The PromiEvent which is a combination of standard Promise and Event Emitter, suggested a promising path as it provided an error event listener:

factoryCampaignContract.methods
  .createCampaign(minimumContribution)
  .send({ from: accounts[0] })
  .on('error', error => console.error('Transaction Error:', error));

Still, the solution wasn’t immediately effective. Digging deeper, I discovered that handling errors effectively required listening for the "error" event before any other .on() handlers for success events (transactionHash, receipt, etc.). The event emitter seems to emit events in the order they’re registered.

Conclusion

Adjusting the order of event handlers was the key. Putting the .on('error', handler) first ensured that any errors, including the infamous “User rejected the request,” were caught and handled appropriately:

factoryCampaignContract.methods
  .createCampaign(minimumContribution)
  .send({ from: accounts[0] })
  .on('error', error => console.error('Transaction Error:', error))
  .on('transactionHash', hash => console.log('Transaction Hash:', hash))
  .on('receipt', receipt => console.log('Transaction Receipt:', receipt));

This nuanced change underscored a crucial aspect of error handling while interfacing with blockchain transactions: event order matters in PromiEvents. This revelation not only stabilized the function of my React app but also enhanced the user experience by providing timely and clear feedback on transaction statuses.