[
https://issues.apache.org/jira/browse/CASSANDRA-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14269375#comment-14269375
]
Sylvain Lebresne commented on CASSANDRA-8528:
---------------------------------------------
bq. I'd like to transport the function to the client
Fair enough. As I said, I was mostly nitpicking on the naming.
{quote}
* new error code for broken functions
* new error code for 'generic' execution exception
{quote}
I don't know, I'd rather not over-engineer it.
For broken functions, this is a very edgy case (especially now that we don't
load classes from the classpath), so it's perfectly fine imho to just reuse
{{FunctionExecutionException}} (or, possibly even better, change the code so it
checks for broken functions at query validation and throw an IRE).
Regarding "generic" execution exception, I didn't said I had something in mind
for that, only that a more generic name could be handy in the future. But it
may not, and I don't think we should add something that may never prove useful.
We can always do it later if we do have a use of it.
> 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)
