Need example of decision table that produces non-null results when there is an error somewhere about tck HOT 4 CLOSED

I think this is implementation specific, but I believe this should not happen. If there is an error, the decision should return null and the error should be published by the engine.

from tck.

It is pretty late here now, but wanted to start a discussion on that topic, because I really think this is a serious problem in the DMN standard:

This is a simple FEEL expression that produces a valid result, even though it contains a semantic error:

{myFn: function(a) a < 5, res: if myFn("6") then "DECLINED" else "ACCEPTED"}.res

Now imagine this is just a tiny part of a huge business model, proceeding to work with the "ACCEPTED" result string which is the result of an error situation (comparing a number with a string) potentially ending up with the approval of an unjustified loan.

I am exaggerating by purposo to point that out clearly.
Imagine how hard it is to debug such stuff, once it is part of a huge model with thousands of expressions and run with unknown data from a webservice or whatever (if "6" was an parameter for this expression).

From my point of view, evaluation must stop at the point where the if statement evaluates against null.
Everything else could be harmful and lead to completely valid looking results and scores based on a semantic error situation.

What is your guys opinion on that?

from tck.

The DMN 1.1 is clear on handling errors. As @etirelli said above, if there is an error, null is propagated up. Both SQL & OCL have a similar approach.

Capturing / propagating errors up to the decision parent can be done via Annotations or at the implementation level (e.g. using a Prolog like accumulator pattern ).

Having an exception-like approach looks like a big change to me.

from tck.

I think we are clear on how error happen and how the testing works around it which is to say that if an error occurs at any point, the "error occurred" flag is set, and it does not matter how many times it is set, nor does it matter if the final result is null or not. The RTF can discuss any possible extensions to the standard. But since the use by the TCK is clear I am going to close this issue.

from tck.