[
https://issues.apache.org/jira/browse/CASSANDRA-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264442#comment-14264442
]
Robert Stupp commented on CASSANDRA-8560:
-----------------------------------------
Making {{CassandraException}} unchecked (extend {{RuntimeException}}): +1 from
my side.
> Make CassandraException be an unchecked exception
> -------------------------------------------------
>
> Key: CASSANDRA-8560
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8560
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Priority: Minor
> Fix For: 3.0
>
>
> {{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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
