Better names and higher granularity for errors

[wprzytula]

Problem statement

There are quite a few places in driver's code where the errors' names and/or messages are inappropriate. Unjustified ProtocolError's usage is prevalent. We lack an error for faults triggered by user's logic, such as unwise custom RetryPolicy being used.

Proposed solution

Add more error variants (mainly for QueryError), fix the usaged to make names and messages appropriate. Stop abusing ProtocolError when no guilt is on received messages.

[roydahan]

What other drivers do for it and the question is if we need to conform into a practice that all drivers agreed upon?

[wprzytula]

What other drivers do for it and the question is if we need to conform into a practice that all drivers agreed upon?

With drivers, error handling depends strongly on the language used.

• Java driver uses exceptions (I suppose Python too);
• gocql uses err type together with various textual error messages;
• Cpp driver returns error code without any additional context;
• Rust driver has a hierarchy of enums that builds up a tree of error types; this could be described in some document (as I asked @muzarski for) and discussed about. In Rust driver, we want strongly typed errors to be able to pattern match on them.

What this issue is about is not making error handling in Rust driver "conformant" to other drivers (because there's no such convention whatsoever), yet it is about changes to the error types hierarchy to make it more reasonable.

[roydahan]

@muzarski / @wprzytula what are the minimal set of errors we would like to handle for this for the 0.14.0 milestone or in general as the "API breaking" item.
I doubt we need to handle all cases right now.

In any case, if easy let's divide them to issues under an umbrella issue and target them to milestones.

[wprzytula]

In the Rust world, all alterations to current errors must be, unfortunately, considered API-breaking. Only after the introduced changes will the error framework be well-suited for changes in a non-API-breaking way. That means that we must do that before 1.0.
But we can, of course, divide the changes into smaller parts and attach to multiple milestones.