<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font size="2">Along the same vein of sensible Bro script error handling, I&#39;m resending an issue I found in January:</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font size="2"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><div class="gmail_default"><font size="2">I
 was tinkering with the sumstats code, and inadvertantly deleted the 
final &quot;}&quot; closing out the last function.  When running the code, the 
misleading error message is received:</font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">error in <span>bro</span>/shar</font><font size="2">e/<span>bro</span>/base/frameworks/<wbr>tunnels/</font><font size="2">./main.<span>bro</span>, line 8: syntax error, at or near &quot;module&quot;</font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">presumably due to the function still being open when the next policy <span>script</span> is loaded.  Wouldn&#39;t it be more reasonable to check at the end of each <span>script</span> when loaded that there are no dangling functions, expressions, etc. ????</font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">==========================</font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">There are also silent fails which probably should give a warning, such as failing to include the fully-qualified event name silently preventing the event from being triggered.<br></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">==========================</font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">The above are more in the area of parsing vs runtime.</font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">My idea on runtime scripting errors would be to apply a sensible default to the offending expression (null or 0, as the case may be, might be sufficient), log the error, and continue....</font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">Jim</font></div><div class="gmail_default"><font size="2"><br></font></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 12, 2018 at 10:27 AM, Jon Siwek <span dir="ltr">&lt;<a href="mailto:jsiwek@corelight.com" target="_blank">jsiwek@corelight.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Trying to broaden the scope of:<br>
<br>
<a href="https://github.com/bro/bro/issues/208" rel="noreferrer" target="_blank">https://github.com/bro/bro/<wbr>issues/208</a><br>
<br>
I recently noticed there&#39;s a range of behaviors in how various<br>
scripting mistakes are treated.  They may (1) abort, as in case of bad<br>
subnet mask or incompatible vector element assignment (2) skip over<br>
evaluating (sub)expression(s), but otherwise continue current function<br>
body, as in case of non-existing table index access or (3) exit the<br>
current function body, as in the classic case of uninitialized record<br>
field access.<br>
<br>
1st question: should these be made more consistent? I&#39;d say yes.<br>
<br>
2nd question: what is the expected way for these to be handled?  I&#39;d<br>
argue that (3) is close to expected behavior, but it&#39;s still weird<br>
that it&#39;s only the *current function body* (yes, *function*, not<br>
event) that exits early -- hard to reason about what sort of arbitrary<br>
code was depending on that function to be fully evaluated and what<br>
other sort of inconsistent state is caused by exiting early.<br>
<br>
I propose, for 2.7, to aim for consistent error handling for scripting<br>
mistakes and that the expected behavior is to unwind all the way to<br>
exiting the current event handler (all its function bodies).  That<br>
makes it easier to explain how to write event handlers such that they<br>
won&#39;t enter too wild/inconsistent of a state should a scripting error<br>
occur: &quot;always write an event handler such that it makes no<br>
assumptions about order/priority of other events handlers&quot;.  That&#39;s<br>
already close to current suggestions/approaches.<br>
<br>
One exception may be within bro_init(), if an error happens at that<br>
time, I&#39;d say it&#39;s fine to completely abort -- it&#39;s unlikely or hard<br>
to say whether Bro would operate well if it proceeded after an error<br>
that early in initialization.<br>
<br>
Thoughts?<br>
<br>
- Jon<br>
______________________________<wbr>_________________<br>
bro-dev mailing list<br>
<a href="mailto:bro-dev@bro.org">bro-dev@bro.org</a><br>
<a href="http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev" rel="noreferrer" target="_blank">http://mailman.icsi.berkeley.<wbr>edu/mailman/listinfo/bro-dev</a><br>
</blockquote></div><br></div>