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 * [email protected] * www.icir.org/robin
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
