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.
that it's only the *current function body* (yes,
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(a)corelight.com * www.corelight.com