Trying to broaden the scope of: https://github.com/bro/bro/issues/208
I recently noticed there's a range of behaviors in how various scripting mistakes are treated. They may (1) abort, as in case of bad subnet mask or incompatible vector element assignment (2) skip over evaluating (sub)expression(s), but otherwise continue current function body, as in case of non-existing table index access or (3) exit the current function body, as in the classic case of uninitialized record field access. 1st question: should these be made more consistent? I'd say yes. 2nd question: what is the expected way for these to be handled? I'd argue that (3) is close to expected behavior, but it's still weird 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. 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). That makes it easier to explain how to write event handlers such that they won't enter too wild/inconsistent of a state should a scripting error occur: "always write an event handler such that it makes no assumptions about order/priority of other events handlers". That's already close to current suggestions/approaches. 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. Thoughts? - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
