[Feature Request] Introduce Typed Errors/Coded Errors

[Xzirez]

Hello,

I have found that operations involving error handling are pretty cumbersome with the library. For example, when debugging the useDApp library, testing clients written on top of the useDApp library, and showing errors to the user there is no good way for me to organize the possible errors I am given. I can see in the code that the errors returned are not typed or have no specific error codes. This makes it harder especially when testing and showing status codes to the user, as I end up testing against strings or having a collection of possible error codes within an error client.

I feel many of these problems could be made easier if the errors were typed, organized with error codes or had a shared error class. I could be mistaken and there might be somewhere in the code where I can see and handle the errors in a more organized way, but so far i have worked with the library for a couple of weeks and I have not located it yet.

I can see that there was some work very recently on the chainId error handling in this Commit

I will provide more context and some possible examples if necessary. There could be a very good reason why the errors are not typed. If so im happy to get a better understanding :)

Example of error thrown given the wrong chainId.

[rzadp]

Thanks for this submission.

I agree 100% - typed errors are good and should be utilized as much as possible.

There are however challenges to it - we can't always know what kind of error we have, because we deal with:

• errors coming from different versions of ethers
• errors coming from API providers
• errors coming from different wallets

So the errors are coming in all different formats, causing attempts to interpret them like this:

useDApp/packages/core/src/hooks/usePromiseTransaction.ts

Line 85 in e89b3d6

const errorMessage = e.error?.data?.message ?? e.error?.message ?? e.reason ?? e.data?.message ?? e.message

---

However, if we can find a way to make sense of it and type errors for some of the cases, and test it with different dependencies, providers and wallets, that would be a good thing.

[Xzirez]

Thank you so much for the insight @rzadp.

I do understand the problem and was also having this issue when testing. If you don't mind I would like to look into if there is a way to handle typed errors for the chainId, as I am currently using this part of the library frequently. If we could unify the error handling of a single service into one format/client first then it would be easy to extend this approach further.

[rzadp]

If you don't mind I would like to look into if there is a way to handle typed errors for the chainId, as I am currently using this part of the library frequently. If we could unify the error handling of a single service into one format/client first then it would be easy to extend this approach further.

Sounds good, let me know if I can help. We can also chat on discord if faster communication is needed around this task.