cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8560) Make CassandraException be an unchecked exception
Date Mon, 05 Jan 2015 10:10:34 GMT


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:
>             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
> * 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

View raw message