[ https://issues.apache.org/jira/browse/CASSANDRA-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Stupp updated CASSANDRA-8528: ------------------------------------ Attachment: 8528-001.txt Attached patch that adds new {{FunctionException}} class that _extends_ {{InvalidRequestException}}. Making {{FunctionException}} a direct subclass of {{RequestValidationException}} turned out to touch half of the source files just to add a _throws/catch_ even in code that can never use UDFs - so I just extended IRE. Additional changes: * use {{assertInvalidMessage}} instead of {{assertInvalid}} in {{UFTest}} + {{AggregationTest}} * add new {{CQLTester.assertInvalidThrow}} + {{CQLTester.assertInvalidThrowMessage}} functions that also tests for the thrown exception (_instanceof_). * some error message fixes > 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)