bsloane1650 commented on a change in pull request #273: WIP: Add User Defined Functions Capability URL: https://github.com/apache/incubator-daffodil/pull/273#discussion_r336720027
########## File path: daffodil-runtime1/src/main/scala/org/apache/daffodil/dpath/UserDefinedFunctionBase.scala ########## @@ -0,0 +1,35 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.daffodil.dpath + +import org.apache.daffodil.exceptions.Assert +import java.lang.reflect.Method +import org.apache.daffodil.udf.UserDefinedFunction + +/** + * Both the evaluate method and the User Defined Function instance are passed in, as both are needed by the Method.invoke + * function. + */ +case class UserDefinedFunctionCall(recipes: List[CompiledDPath], userDefinedFunction: UserDefinedFunction, evaluateFxn: Method) + extends FNArgsList(recipes) { + override def computeValue(values: List[Any], dstate: DState) = { + val jValues = values.map { _.asInstanceOf[Object] } + val res = evaluateFxn.invoke(userDefinedFunction, jValues: _*) Review comment: Our expression exception try-catch is defined in DPath.scala as "handleThrow()". By design, this block only captures exceptions which we expect to be triggerable by problems in the DPath expression itself; and (to the extent possible) not exceptions that are caused by genuine bugs in Daffodil. Since UDFs are implemented as arbitrary Java/Scala code, it is possible for them to throw any exception. For example, if a UDF throws a ClassCastException, we want to capture it and treat is as a some sort of user error [0]. However, if that same exception gets thrown from Daffodil code, it is a Daffodil Bug, and should get the "this is a bug in Daffodil" message. I would say that we add a UserDefinedFunctionException say that UDFs are only allowed to throw UserDefinedFunctionException`s, which are interpreted as a correct result indicated that the DPath expression results in an error. Any exception thrown which is not a UserDefinedFunctionException is intereprated as the UDF implementation itself had an error, so we do not know if the DPath expression that was being computed should have succeeded. If the exception being thrown is a UserDefinedFunctionException, I think we can put the responsibility on the UDF author to include sufficient information. For any other exception, we should provide backtrace of the code capturing the portion of the stack below UDF entry point. Whatever we decide, I think error handling should be added to the design proposal. [0] originally I thought a standard Processing Error for which we can backtrack; but now that I write this out, I think an unsupported exception type should be fatal regardless of backtracking. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
