Use in-house Web3 exceptions for all of the codebase

[fselmo]

What was wrong?

• closes Use Web3Exception for all exceptions within the library #3241

How was it fixed?

• Instead of ValueError, raise Web3ValueError and extend from ValueError and Web3Exception
• Instead of TypeError, raise Web3TypeError and extend from TypeError and Web3Exception
• Instead of AssertionError, raise Web3AssertionError and extend from AssertionError and Web3Exception
• Instead of AttributeError, raise Web3AttributeError and extend from AttributeError and Web3Exception
• Add ENSValueError and ENSTypeError as well. Seems like that could only help with better control over exception handling.

Todo:

• Add entry to the release notes

Cute Animal Picture

[reedsa]

No major concerns, lgtm!

Noticed two empty files, tests/core/pm-module/test_ens_integration.py and web3/tools/pytest_ethereum/deployer.py

[fselmo]

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.

[LefterisJP]

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

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.

[fselmo]

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.

[reedsa]

Lgtm

[kclowes]

This looks great! I left one nit on a file name, but that was all I saw. It'll be great to get this in!