Improve Readability of error.message

[RauppRafael]

Ethers Version

6.6.3

Search Terms

error message handling

Describe the Problem

In the ethers documentation, it's stated that:

"All errors in ethers include properties to ensure they are both human-readable (i.e. .message) and machine-readable (i.e. .code)."

However, I'm finding the actual error.message field is less than ideal from a human readability standpoint. Currently, the output is as follows:

user rejected action (action="sendTransaction", reason="rejected", info={ "error": { "code": 4001, "message": "ethers-user-denied: MetaMask Tx Signature: User denied transaction signature." }, "payload": { "id": 25, "jsonrpc": "2.0", "method": "eth_sendTransaction", "params": [ { "from": "0x....", "gas": "0xa410", "to": "0x....", "value": "0x...." } ] } }, code=ACTION_REJECTED, version=6.6.2)

It seems overly verbose for the message property to include all this information, given that the same data is available in other properties of the error object.

To improve readability, it would be more beneficial if the error.message only contained the essential information related to the error, such as: user rejected action. This would make it more user-friendly and easier to understand at a glance.

Environment

Ethereum (mainnet/ropsten/rinkeby/goerli)

[ricmoo]

The main reason all the data is included is because I receive a LOT of GitHub issues, email correspondence, Twitter DMs, etc. and people only post the error message, they don't bother including the specifics of the error. Because of all this extra data I can usually diagnose the entire issue immediately without having to request further info.

The format is usually a short description, followed by data within parenthesis. Would including longer descriptions in front of the parenthesis help? I lost a LOT of development time prior to this, going back and forth with developers trying to get help understanding their issue. That is also why the version is also included; often people just need to update their version. :)

It probably also makes sense to put the error code first.

I'm open to discussion, but with ethers I provide a lot of assistance, and spend a lot of time on Discord helping people, so having errors that makes it easy to debug in one-shot saves me a lot of time.

[iankressin]

What if there's a field for a "short error message"? You'd still have error.message with all the information for debugging and a clearer error message that can be used to display errors to users on front-end apps

[RauppRafael]

I @ricmoo completely understand your point, and it certainly makes sense to have the full error details readily available for quick diagnosis and resolution.

I believe @iankressin has proposed a practical solution that caters to both needs. By introducing a new field, for example, error.shortMessage, we can provide a simplified, human-readable error message for front-end display, without losing the detailed debugging information. The error.message field can remain as it is for diagnostic purposes.

Another viable alternative could be to reverse the roles: error.message could contain the simplified, human-readable message for ease of understanding and immediate display to users, while a new field, such as error.detailedMessage, could carry the comprehensive error information necessary for debugging.

Either of these proposals - whether the short message goes into error.message or a new error.shortMessage field - would provide a more accessible error message for user interaction while keeping the detailed information for diagnostic purposes. I'm comfortable with whichever solution best fits the project's needs and conventions.

[ricmoo]

Yeah, and that should be a fairly simple change, since all errors are generated through a common error creation function. I can also expand on the human-readable component then, since the entire payload won't be present.

I feel I'd rather keep the the detailed version in the .message mainly because the type of people who "just post the error" are already the type of people that don't usually dig much further into the problem, and I'd be constantly posting "can you please include console.log(error.detailedMessage) which also delays resolution (of simple issues) by an entire round-trip of communication. :)

[iankressin]

That makes a lot of sense. error.shortMessage would be really valuable for better error handling

[RauppRafael]

I agree. When can we see that property available, @ricmoo?

[ricmoo]

I'll mark it for the next minor bump. :)