On Mon, Nov 12, 2018 at 1:44 PM Jim Mellander <jmellan...@lbl.gov> wrote:
> I was tinkering with the sumstats code, and inadvertantly deleted the final > "}" closing out the last function. When running the code, the misleading > error message is received: Yes, that's a bit of a different topic, but still tracked (at low-normal priority): https://github.com/bro/bro/issues/167 > 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. Also a bit different that what I was talking about, but also tracked (at higher priority since it's a common mistake): https://github.com/bro/bro/issues/163 > 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.... In the following example (comments reflect current behavior) you'd expect the "false" branch in foo() to be taken? ################################# function foo() { local t: table[string] of string = table(); # Non-existing index access: (sub)expressions are not evaluated if ( t["nope"] == "nope" ) # Unreachable print "yes"; else # Unreachable print "no"; # Reachable print "foo done"; } event bro_init() { foo(); # Reachable print "bro_init done"; } ################################# My thought was that should behave more like a "key error" run-time exception (e.g. like Python). Bro scripting doesn't have exception support, but internally we can use an exception to unwind the call stack (additionally I was thinking that the unwind needs to proceed further than what it does already in some cases, which is just the current function body). In any case, logging of the error would also occur (as it already does). - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
