[ 
https://issues.apache.org/jira/browse/CASSANDRA-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264400#comment-14264400
 ] 

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: https://issues.apache.org/jira/browse/CASSANDRA-8528
>             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
(v6.3.4#6332)

Reply via email to