Assertion failures create a new AssertionFailed object (which is a
ParseError) and sets it as the processorStatus. It also is added to the
list of diagnostics. So you should be able to inspect the
processorStatus or diagnostics to get that information.
Note that the CLI does not break on failures by default, so if you are
using breakpoints it is possible that backtracking could cause the
processorStatus/diagnostics to be lost by the time you hit a breakpoint.
If you use "step" to walk through a parse in the CLI debugger instead of
using a breakpoint, you should see failed assertion. You can also run
"set breakOnFailure true" in the CLI debugger to cause it to pause
whenever a parser error occurs.
On 2023-06-14 01:31 PM, Shane Dell wrote:
Hey Mike,
Does the CLI version of the debugger handle asserts failing? If so could you
point in the
direction of the file that handles that? Currently I seem to have issues
grabbing the error to
display into the console. I thought the ParseResult might fail but it didn't
seem like it did and
the vscode debugger seems to end debugging as if everything was fine even
though it fails that
assert.
Thank you,
Shane Dell
On 2023/06/13 15:54:07 Mike Beckerle wrote:
Shane,
648 I added info to the ticket. Basically make icmp1.bad.cmp where byte 1
is clobbered to be 0x00.
649, just modify the pcap.dfdl.xsd to make it not compile. E.g., put a
typographical error in some DFDL property name.
I agree with your assessment that the above 2 make sense for 1.3.0, but the
bigger issue 653 can be postponed to the next release.
I closed 651 as duplicate as you suggested.
Delaying Issue 76 until the next version makes sense to me also.
On Tue, Jun 13, 2023 at 11:39 AM Dell, Shane <[email protected]> wrote:
Hey Mike,
I needed some clarification on some of the issues you added into
daffodil-vscode.
For issue https://github.com/apache/daffodil-vscode/issues/648 I could
use some more information on how you clobbered the magic number to make the
assert fail. As for issue
https://github.com/apache/daffodil-vscode/issues/649 I could use some
more information on how to reproduce this as well. I believe these issues
would be desired for 1.3.0 but I think the root element issue
https://github.com/apache/daffodil-vscode/issues/653 should probably go
to 1.3.1 since I think that might be a bigger thing. I also believe issue
https://github.com/apache/daffodil-vscode/issues/651 should be closed as
we already have a similar issue (
https://github.com/apache/daffodil-vscode/issues/76) to support adding
breakpoints to schemas in JARs that is planned for 1.4.0. What are your
thoughts?
Thank you,
Shane Dell
This message and any files transmitted within are intended solely for the
addressee or its representative and may contain company sensitive
information. If you are not the intended recipient, notify the sender
immediately and delete this message. Publication, reproduction,
forwarding, or content disclosure is prohibited without the consent of the
original sender and may be unlawful.
Concurrent Technologies Corporation and its Affiliates.
www.ctc.com 1-800-282-4392
