[GitHub] [incubator-daffodil] stevedlawrence commented on a change in pull request #204: Provide more detail for failed assertions

[GitBox <gi...@apache.org>]

stevedlawrence commented on a change in pull request #204: Provide more detail for failed assertions
URL: https://github.com/apache/incubator-daffodil/pull/204#discussion_r272614889
 
 

 ##########
 File path: daffodil-runtime1/src/main/scala/org/apache/daffodil/processors/parsers/AssertPatternParsers.scala
 ##########
 @@ -75,7 +77,16 @@ class AssertPatternParser(
       val isMatch = dis.lookingAt(m, start)
       if (!isMatch) {
         val message = getAssertFailureMessage(start)
-        val diag = new AssertionFailed(context.schemaFileLocation, start, message)
+
+        Assert.invariant(start.currentNode.isDefined)
+        val currentElem = start.currentNode.get
+        val details = if (currentElem.isSimple) {
+          "\nParsed value was: " + currentElem.toString
+        } else {
+          "<" + currentElem.name + ">...</" + currentElem.name + ">"
+        }
+
+        val diag = new AssertionFailed(context.schemaFileLocation, start, message, Maybe.One(details))
 
 Review comment:
   I'm not sure if this change makes sense in all cases.  One case might be if a dfdl:assert has a ``message`` attribute. I would argue that in that case we do not want to alter the users message at all, which is what this does.
   
   Instead, maybe the bug can be inerpreted as really asking for a better *default* assertion failed message when a schema doesn't provide a ``message`` attribute. Right now, that default is defined in PrimitievsExpression.scala as just ``exprWithBraces + " failed"``. Considering that the assertion could check for anything, this actually seems somehwat reasonsable to me, especially since just knowing the value of the current element isn't going to that useful in many cases. For example, what if the assertion expression was ``{ xs:int(.) gt ../SomeElement }``. In this case, knowing the value of the current element isn't enough information. You also want to know the value of ../SomeElement.
   
   I've seen some assertion libraries that will generate an assertion message that is the string version of the assertion, but with variables replaced with their runtime values. So for the above assertion, we might generate a default message expression that look like this:
   ```
   { fn:concat("{ xs:int(", ., ") gt ", ../SomeElement, " }", "failed") } 
   ```
   And when evaluated would result in somethign like this:
   ```
   { xs:int(2) gt 5 } failed
   ```
   That of course gets really complicated since you need to be able to convert your expression to a fn:concat thing with all the pieces being a string except for the variables. That might not be too difficult with our expression tree stuff, but I'm not sure it's worth the effort, especially since if a user really cared they could make that message theirself.

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services