I’m still new at this – but I’ve found a great way to learn is to invite people to tell me I’m wrong, so here’s my two cents.
SDE in particular is generally used to tell the parser that something has gone wrong. This invites the parser to either back up to the most recent point of uncertainty and try another path or fail completely if none exists. That’s how we select one branch over another in the cases where there are multiple possible paths. If we do select a path that turns out to be invalid, we generally don’t want those errors to propagate back up the chain, since they are for a “path not taken” and failing in a way that leads us to the correct path is both expected and desired behavior. By extension, warnings encountered on our “path not taken” also get discarded since. For instance, if we have a regex failure looking for the length of a discriminator that ultimately doesn’t exist because this is an invalid path - that isn’t really a failure at the top level. So using SDW for a global “something weird you might want to examine” sort of warning is somewhat at odds with the way SDE and SDW are usually used. Our runtime does generate quite a bit of text – so simply printing to console for a warning is likely to be missed. If we want to have a sort of global log that doesn’t get cleared, but also isn’t mingled with the runtime console output – we may need a new facility for that. Side note – there are certain classes of diagnostics around choice branches that don’t get discarded currently, which may cause some warnings and errors to escape even though we output a successful infoset. Ticket 2399 discusses this issue, and a partial attempt at a fix is languishing WIP on https://github.com/apache/incubator-daffodil/pull/444. The short version being that I wouldn’t want to rely on any information from SDW or SDE escaping a “path not taken” once that fix is in place. [A picture containing object, clock Description automatically generated] Ian Carlson | Software Engineer [Owl Cyber Defense] W icarl...@owlcyberdefense.com<https://owlcyberdefense.com/> Connect with us! Facebook<https://www.facebook.com/owlcyberdefense/> | LinkedIn<https://www.linkedin.com/company/owlcyberdefense/> | Twitter<https://twitter.com/owlcyberdefense> [Find us at our next event. Click Here.]<https://owlcyberdefense.com/resources/events/?utm_source=owl-cyber-defense&utm_medium=email&utm_content=banner&utm_campaign=2020-events> The information contained in this transmission is for the personal and confidential use of the individual or entity to which it is addressed. If the reader is not the intended recipient, you are hereby notified that any review, dissemination, or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify the sender immediately From: Larry Barber<mailto:larry.bar...@nteligen.com> Sent: Friday, December 18, 2020 12:49 PM To: dev@daffodil.apache.org<mailto:dev@daffodil.apache.org> Subject: How to add warnings that are not lost due to backtracking I hoping someone could give me some pointers on adding a warning message to the Daffodil io code. I'm looking at Daffodil-412 and want to generate a warning message when the REGex search gets expanded and another if it exceeds the tunable for maximum length. I've located the code that does these expansions in io/InputSourceDaraInputStream.scala, but I'm unsure how to generate the warning messages. I don't see any other warning messages being generated in the io code. I've seen several instances in core that just use SDW(...) and others in DSOM that use context.SDW(...), but I'm confused about this - I'm afraid that this method buffers warnings and throws them away in the case of backtracking. Since the REGex search may be the cause of backtracking, I think these warnings need to be presented always. I'm just not sure of the proper way to access SDW in this situation and need to make sure that the messages will not be discarded.
