Closed fselmo closed 5 months ago
My ultimate question here is whether or not it answers the call to have a more specific error thrown? I suppose we can take care of that part after as well. This helps with user exception handling, ideally catching all (or close to all) web3.py
errors by catching Web3Exception
or any combination of exceptions that inherit from it for fine-tuning. But if we want to throw an error that isn't so generic as any value error is bound to be I think we should probably end up tracking that in a separate ticket maybe?
@kclowes I'll wait for your review / input on this since you seem to be in this conversation quite a while longer than I.
cc: @LefterisJP for input via this comment.
This helps with user exception handling, ideally catching all (or close to all)
web3.py
errors by catchingWeb3Exception
or any combination of exceptions that inherit from it for fine-tuning
Exactly this is what prompted my original comment. To be able to catch all the library errors easily and not have to add extra except
clauses whenever a user does something that raises a ValueError
, or TypeError
which we did not expect.
But if we want to throw an error that isn't so generic as any value error is bound to be I think we should probably end up tracking that in a separate ticket maybe?
I am not sure I understand what you mean here. What kind of error would not be generic? Can you maybe give an example?
cc @yabirgb from the rotki team here just an fyi for the upcoming changes and for potential input.
I am not sure I understand what you mean here. What kind of error would not be generic? Can you maybe give an example?
I think your answer covered it. I just mean that in some cases a more specific class name may make more sense. Something like Web3RPCError
but I get the sense that the important part for you was fine tuning what is coming from the library and not how generic the exception scope was.
What was wrong?
How was it fixed?
ValueError
, raiseWeb3ValueError
and extend fromValueError
andWeb3Exception
TypeError
, raiseWeb3TypeError
and extend fromTypeError
andWeb3Exception
AssertionError
, raiseWeb3AssertionError
and extend fromAssertionError
andWeb3Exception
AttributeError
, raiseWeb3AttributeError
and extend fromAttributeError
andWeb3Exception
ENSValueError
andENSTypeError
as well. Seems like that could only help with better control over exception handling.Todo:
Cute Animal Picture