cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8528) Add an ExecutionException to the protocol
Date Mon, 05 Jan 2015 09:32:36 GMT


Sylvain Lebresne commented on CASSANDRA-8528:

bq. that extends InvalidRequestException

The main reason we want a new exception here is that there is cases where function can fail
during the query execution (if it's in a select clause/an aggregation and it fails on some
particular input). In those cases, it's definitively not the query that is invalid and that's
why we need something else. So the new exception should extend neither {{InvalidRequestException}}
nor {{RequestValidationException}}, but rather {{RequestExecutionException}}.

That doing so forces us to add lots of throws/catch is infortunate, but it's not reason enough
to do the wrong thing. That said, I happen to think that we would be better off by making
{{CassandraException}} (that both {{RequestValidationException}} and {{RequestExecutionException}}
extends) a {{RuntimeException}}. So I've created CASSANDRA-8560 to make that change. I suggest
we wait a week or so to see if CASSANDRA-8560 is too contentious, and if it's not, do it first
and this ticket second.

bq. adds new {{FunctionException}} class

I'm nitpicking, but {{ExecutionException}} or {{FunctionExecutionException}} sounds better
to my hears than {{FunctionException}}. {{ExecutionException}} has the slight advantage that
it's not absolutely function specific and so it might be suitable for something else someday,
which could be handy. But that may or may not be a good idea in the first place so I'm fine
with {{FunctionExecutionException}}.

> Add an ExecutionException to the protocol
> -----------------------------------------
>                 Key: CASSANDRA-8528
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Sylvain Lebresne
>            Assignee: Robert Stupp
>              Labels: client-impacting, protocolv4
>             Fix For: 3.0
>         Attachments: 8528-001.txt
> With the introduction of UDF, we should add an ExecutionException (or FunctionExecutionException
or something like that) to the exceptions that can be sent back to client. We can't guarantee
that UDFs won't throw and none of our existing exception is terribly adapted to report such
event to the client.

This message was sent by Atlassian JIRA

View raw message