Gotcha, thank you very much for the information. This helped me find the area where to check the parse for errors and throw them.
On 2023/06/14 17:57:07 Steve Lawrence wrote: > 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 > >>> > >>> > >> > >
