Above screenshot is taken from the following PR review: namehash/ensawards#60
Note the error handling logic here that is associated with possible failures from the network request made by resolveEthAddress.
I find it really nasty that devs building on ENSNode would need to write such logic for each request they might make to ENSNode.
It seems it would be much nicer if we offered a structured / well-typed strategy for handling all possible errors, including:
- connection lost
- request timeout
- server error
- etc..
We can't change the fact how in TypeScript error is always Unknown or something like that from my memory.
A strategy I would be curious about includes defining some helper function that could be used inside the catch block where an Unknown error object could be passed in and it would always return some well structured ENSNodeError object. Here it might check if the Unknown error object is truly an instance of ENSNodeError and if so, return that. If not, it might apply some strategy for converting the error object to an ENSNodeError object or generating one that might be associated with an "Unknown Error" as an ultimate fallback.
Ideally the logic inside the ENSNode client would internally catch generic errors such as connection lost / request timeout / etc.. and translate them into an ENSNodeError.
Ultimately it seems really nice if these catch blocks could simply have a switch statement for a well-defined set of error codes such that clients can confidently implement a really good UX on top of requests they send to ENSNode.
Very open to alternative suggestions. Advice appreciated 👍
Above screenshot is taken from the following PR review: namehash/ensawards#60
Note the error handling logic here that is associated with possible failures from the network request made by
resolveEthAddress.I find it really nasty that devs building on ENSNode would need to write such logic for each request they might make to ENSNode.
It seems it would be much nicer if we offered a structured / well-typed strategy for handling all possible errors, including:
We can't change the fact how in TypeScript
erroris always Unknown or something like that from my memory.A strategy I would be curious about includes defining some helper function that could be used inside the catch block where an Unknown error object could be passed in and it would always return some well structured ENSNodeError object. Here it might check if the Unknown error object is truly an instance of ENSNodeError and if so, return that. If not, it might apply some strategy for converting the error object to an ENSNodeError object or generating one that might be associated with an "Unknown Error" as an ultimate fallback.
Ideally the logic inside the ENSNode client would internally catch generic errors such as connection lost / request timeout / etc.. and translate them into an ENSNodeError.
Ultimately it seems really nice if these catch blocks could simply have a
switchstatement for a well-defined set of error codes such that clients can confidently implement a really good UX on top of requests they send to ENSNode.Very open to alternative suggestions. Advice appreciated 👍