Remove unnecessary exception catching

[davesque]

What was wrong?

Exceptions generated by eth-abi are fairly descriptive. It seems a bit
redundant to wrap encoding exceptions with this extra message and also
filter out the original exception type.

Also, some code wrapped in this try/except block could never throw EncodingError exceptions.

I poked around and it doesn't look like any dependent code is expecting a TypeError specifically. Also, the test suite still seems to pass. So I'm not sure if there's much risk here.

How was it fixed?

Removed the relevant try/except block.

Cute Animal Picture

[carver]

Yeah, I think the argument was roughly that end-user libraries, like web3, should avoid raising custom exceptions, preferring builtins. I think I still like that approach in general, but don't feel strongly about it. Up to you 👍

[davesque]

@carver

What's the reasoning behind that? Is it that it's annoying to have to import exceptions to catch them?

I think I noticed that and tried to follow suit, but eventually I got frustrated that there isn't always a built-in exception that seems appropriate for the given situation. Then, I just broke down and went back to having a custom set of Exception subclasses for the library.

One reason I kinda like that is exceptions can more directly correspond to the task that's being done e.g. EncodingError getting raised during encoding of values.

[davesque]

This situation is a good example of what I'm talking about, by the way. It's confusing that TypeError is being raised to signal some problem with encoding a certain value. I might have expected that ValueError would be raised. It seems like the appropriate use of those two built-ins can sometimes be a bit subjective and different people's preferences might not be consistent with each other. On the other hand, I don't feel like anyone would be confused if something called EncodingError was raised when calling something named encode_abi.

[carver]

What's the reasoning behind that? Is it that it's annoying to have to import exceptions to catch them?

Yeah, that seems about right. Roughly that the global exceptions are a nice standard to rally around. When possible, it's better to stick to a global standard than a project-level one. Like I said, not a strong feeling though (at a basic level, someone naturally has to learn your API to work with your library).

I don't feel like anyone would be confused if something called EncodingError was raised when calling something named encode_abi.

Sounds good to me 👍