[Bro-Dev] Consistent error handling for scripting mistakes

Robin Sommer robin at corelight.com
Mon Nov 12 20:39:49 PST 2018

On Mon, Nov 12, 2018 at 12:27 -0600, Jonathan Siwek wrote:

> I recently noticed there's a range of behaviors in how various
> scripting mistakes are treated.

There's a 4th: InterpreterException.

> 1st question: should these be made more consistent? I'd say yes.

Yes, definitely.

> that it's only the *current function body* (yes, *function*, not
> event) that exits early -- hard to reason about what sort of arbitrary
> code was depending on that function to be fully evaluated and what
> other sort of inconsistent state is caused by exiting early.

... and what happens if the function is supposed to return a value,
but now doesn't?

> I propose, for 2.7, to aim for consistent error handling for scripting
> mistakes and that the expected behavior is to unwind all the way to
> exiting the current event handler (all its function bodies).

Agree with that. Can we do that cleanly though? The problem with
InterpreterException is that it may leak memory. We'd need to do the
unwinding manually throughout the interpreter code, but that means
touching a number of places to pass the error information back.

> One exception may be within bro_init(), if an error happens at that
> time, I'd say it's fine to completely abort -- it's unlikely or hard
> to say whether Bro would operate well if it proceeded after an error
> that early in initialization.

Yeah, that makes sense.


Robin Sommer * Corelight, Inc. * robin at corelight.com * www.corelight.com

More information about the bro-dev mailing list