[ESI] Throw exceptions on invalid deserialization

[mortbopet]

... Instead of deserializers throwing internal errors, e.g. when trying to read beyond a bytes object's actual size.

[teqdruid]

The problem with this approach is if one has a deeply nested type and an exception is raised in one of the leaves, this will create a long message in the text rather than a backtrace which is far more useful in debugging.

Perhaps the right way is to output errors to the logger...

[mortbopet]

The problem with this approach is if one has a deeply nested type and an exception is raised in one of the leaves, this will create a long message in the text rather than a backtrace which is far more useful in debugging.

Disagree. This change was motivated by the fact that the stack trace wasn't giving sufficient information about what actually went wrong in the deserialization. Yes, you get the exact location, but beyond that you're on your own. I feel like sprinkling a bit of human-readable explanation in here is completely valid.

[teqdruid]

Thinking about this some more, where the deserialization error occurred is not relevant to users. In all cases the error boils down to "message was not the correct size". At what point in the deserialization it ran out of date is likely to be a red herring since we don't know which bytes are actually missing. Did we not get some bytes at the beginning? Were some bytes in the middle skipped? This is really only useful if the missing bytes are at the end and it's not clear to me that this will always be the case. We're probably best of stating there's a size mismatch (expected vs actual overall message size) since that's what we actually know for sure.