Details
-
Improvement
-
Status: Resolved
-
Low
-
Resolution: Fixed
-
None
-
None
Description
CassandraException (which is the base class of our query validation and execution exception, including InvalidRequestException, UnavailableException, ...) is a checked exception. Those exceptions are pervasive and are rarely meant to be caught within Cassandra since they are meant for reporting problems to the end user and so I'm not convinced the benefit of checked exceptions outweight the cost of having to put throws everywhere.
Concretely, the fact that these are checked exception is currently a pain for 2 outstanding tickets:
CASSANDRA-8528: as Robert put it, it forces to "touch half of the source files just to add a throws/catch even in code that can never use UDFs"CASSANDRA-8099: the ticket transform some code (in StorageProxy for instance) to iterators, but an iterator can't throw checked exception. In fact, the current WIP patch for that ticket already switch CassandraException to extend RuntimeException for that very reason.
I understand that "checked" vs "unchecked" exceptions is an old debate with proponent of both camp, but I'm pretty sure the costs of checked outweight the cons in that case.
Attachments
Attachments
Issue Links
- blocks
-
CASSANDRA-8528 Add an ExecutionException to the protocol
- Resolved