[
https://issues.apache.org/jira/browse/CASSANDRA-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13430683#comment-13430683
]
Sylvain Lebresne commented on CASSANDRA-3979:
---------------------------------------------
Doing this, I wanted to use the occasion to improve our "exception situation".
Typically, the binary protocol give us a chance to return more precise
exceptions to the client. I also wanted to remove the thrift exceptions from
our internal code as part of the 'kill thrift initiative'.
The resulting patch, pushed at
https://github.com/pcmanus/cassandra/commits/3979, is arguably pretty damn big.
However a good part is fairly mechanical and boring, like renaming imports from
org.apache.cassandra.thrift.SomeException to
org.apache.cassandra.exceptions.SomeException.
But to try to sum that up, the patch does the following things:
* it remove the use of thrift exceptions internally, creating a new hiearchy of
internal exceptions that are translated to the old thrift ones on the thrift
side. The new exceptions are all in a exceptions package (and so I move
config.ConfigurationException to exceptions.ConfigurationException, though I
have to admit this is a bit artificial).
* this new exception "hierarchy" tries to be a little more precise than the old
one. There is 2 family of exceptions: RequestValidationException when something
is wrong with the request itself and RequestExecutionException when the request
is fine but couldn't complete correctly. But then RequestValidationException
distinguishes:
** authorization exception (if checkaccess fails basically)
** configuration exception (the same as before)
** syntax exception (for the parse errors)
** AlreadyExistsException (when you create a keyspace or table but it already
exists. I think it is very useful for clients to be able to detect those from
other validation exception)
** invalid request exception (a request invalid for some other reason than
what's above)
* then RequestExecutionException distinguishes:
** unavailable exception (can't achieve CL and I know it)
** timeout exception; the patch introduce a write and read timeout, since for
CQL clients you might want to make a distinction and don't know if you're query
was a read or a write (unless you parse it).
** IsBootstrappingException. If you try to read from a boostrapping node. We
use to shove that in unavailable, but while the name "unavailalbe" fits, it's
still a different exception from not being to achieve CL.
** Truncate error: truncate as it's own reason to fail that don't fully fit
the other exceptions imho.
** overloaded exception. There is only one case where that happens, it is
during write if there is too much in-fligh hints. Again, we used to just throw
unavailable, but it's worth distinguishing the case imho.
* All this new "hierachy" of exception is supported by/exposed to the binary
protocol with documented error codes.
* The patch also adds a bit more info to the unavailable and timeout exception,
namely the CL, the number of ack received and the number of acks we were
blocking for (and for readTimeout if we received data). I strongly believe this
information is useful to clients to decide correctly whether to retry or not.
* it also creates a db.ConsistencyLevel to replace thrift.ConsistencyLevel
internally, just so that there is no thrift structure in the new internal
timeout exception.
> Consider providing error code with exceptions (and documenting them)
> --------------------------------------------------------------------
>
> Key: CASSANDRA-3979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3979
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
> Reporter: Sylvain Lebresne
> Labels: cql3
> Fix For: 1.2
>
>
> It could be a good idea to assign documented error code for the different
> exception raised. Currently, one may have to parse the exception string (say
> if one wants to know if its 'create keyspace' failed because the keyspace
> already exists versus other kind of exception), but it means we cannot
> improve the error message at the risk of breaking client code. Adding
> documented error codes with the message would avoid this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
