stevedlawrence commented on a change in pull request #12: Revised daffodil-io 
module to require passing in a FormatInfo object.
URL: https://github.com/apache/incubator-daffodil/pull/12#discussion_r158339327
 
 

 ##########
 File path: 
daffodil-runtime1/src/main/scala/edu/illinois/ncsa/daffodil/debugger/InteractiveDebugger.scala
 ##########
 @@ -1078,6 +1078,35 @@ class InteractiveDebugger(runner: 
InteractiveDebuggerRunner, eCompilers: Express
           //          case e: ExpressionEvaluationException => println(e)
           //          case e: InfosetException => println(e)
           //          case e: VariableException => println(e)
+
+          //
+          // mbeckerle: I am unsure why this hack is needed now, but was not 
before.
+          // Now if we eval(.) on a node that has no value, we get a RSDE 
thrown.
+          // I see no code before (or now) to catch this RSDE, to not create 
this
+          // RSDE under this situation where the debugger is getting the 
error, etc.
+          //
+          // A test in daffodil's cli module sets up a 'display eval (.)' and 
then
+          // single steps until on a cell element of a matrix, and at that 
point the
+          // cell has not been parsed and so has no value.
+          //
+          // This test test_1326_CLI_Debugger_displaysTesting, used to pass.
+          // Without this hack below, it fails because of the RSDE being 
thrown due
+          // to the lack of value in the cell element.  The test is expecting
+          // </tns:matrix> which makes no sense, as that would never have been 
the
+          // right thing to be displayed in this situation. It should either 
print
+          // some representation of no-value, or print the element (which 
would be empty)
+          // but there is no explaining it displaying the entire matrix.
+          //
 
 Review comment:
   I'm not sure this is really a hack. I think this is the correct thing. I 
think the reason this caused a failure now is because some parers removed so it 
gets to a certain state earlier. If you the same test on master, but just keep 
stepping through, it eventually fails with the same error. So I think is is 
correct, as much as it seems like a hack. Only thing I wonder is if we need the 
state.setSuccess() on other exceptions. And is that okay to just always 
setSuccess? What if the pstate failed, we evail, and then call 
state.setSucces(), and now the pstate things it succeeded?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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

Reply via email to