error types

[novaknole]

Hi Richard, @ricmoo

Currently, in my app, I do the following:

try {
       await contract.function()
      } catch (error) {
       console.log(error.error.message)
      }

I really don't like error.error.message.

1. what would be a good way to deal with this ? I also use the typescript. which type is error in the catch block ?
2. if I use the type, and still go on with error.error.message, if I change the ethers.js to some other library, I guess, type of the error doesn't follow the same standard across different packages. right ? Any idea how it can be done so that changing packages from ethers to web3 doesn't affect too much my code ?

[ricmoo]

The sub-error messages are generally things that were not machine readable and provided for humans to debug. I try to parse anything meaningful to code into the error as the error.code, so this message isn’t intended to be something actionable, and more so just something to ensure additional info that may be useful is not discarded entirely.

There isn’t really any plans to make these messages portable, since there is no way to interpret it. If you have a situation where the message could be more thoroughly parsed (that would work across various backends), I’m more than willing to parse it out and include additional details directly on the error object.

Does that make sense?

[novaknole]

yeah, makes sense..

@ricmoo

Do we have at least types for error ? I am using typescript and this is why i am asking if it's possible.

[ricmoo]

I think all errors in TypeScript are emitted as unknown, but I noticed there was something about a new feature on the TS 4.3 road map?

Or is there currently a better way to indicate the error envelope?

Sub-classing errors does not work well across all environments yet, so at best, an interface could be provided to cast it to, if that is what you mean?

[novaknole]

doing interface is better, but since errors are thrown as unknown, it's not going to check if it throws the valid ones or not..

I guess, doing error.error.message seems fine as of now. Can't think of a better way for now.