On Wed, Dec 14, 2016 at 09:39 -0500, you wrote:
> I like that too. Having nicely generalized error handling in Bro > would be such a huge benefit for script authors. So let's think that through. Let's say we did an Error enum that can reflect various error conditions, something like this: local v = Broker::lookup(h, 42) # Continues to return 'opaque of Broker::Data' if ( v == Error::Success ) print (v as string); else if ( v == Error::NotFound ) print("not found"); else if ( v == Error::Timeout ) print("timeout"); else print("unknown error"); } (That could also be a switch statement, naturally). I think that looks pretty good. But where's that Error type defined? Is it a new global type that Bro predefines for everybody to use? Then we'd either need to limit the type of errors to a small predefined set, or allow scripts to redef the enum and add their own types; but the latter risks naming clashes. Alternatively, we could leave it to frameworks to define their own error types. So for Broker, we'd have Broker::NotFound, Broker::Timeout, etc. And the opaque types would define internally what they convert to, and how. Seth, a question: do you have more in mind by "nicely generalized error handling" than this? Do you see a way to generalize this to purely script-level logic (i.e., no opaques, just normal Bro types being passed around)? Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev