[Bro-Dev] Consistent error handling for scripting mistakes

Jon Siwek jsiwek at corelight.com
Mon Nov 12 12:24:47 PST 2018


On Mon, Nov 12, 2018 at 1:44 PM Jim Mellander <jmellander at 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


More information about the bro-dev mailing list