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. :)

[RauppRafael]

Any updates @ricmoo ?

[ricmoo]

Yes, I have a local branch with the necessary changes made and have just been experimenting with it to make sure there aren't any backwards incompatibilities introduced.

It will happen over several steps. The first will be to update the makeError and most common assert statements (like assertArgument), and then over time I'll add more details to error emitted throughout the library.

[ricmoo]

The first step of this has been added in v6.8.0.

The shortMessage will always be added as the message passed to assert, makeError, etc. unless overridden by a value in the errorInfo.shortMessage. Please let me know if you happen across any errors you would like additional context added to the shortMessage, since it is easy to add without affecting anything else. :)

[iankressin]

awesome @ricmoo, thank you so much!