[Bro-Dev] [Proposal] Language extensions for better Broker support
Matthias Vallentin
vallentin at icir.org
Tue Dec 13 09:42:10 PST 2016
> > local r = put(store, key, test(lookup(store, key)));
>
> For prototyping purposes, I see the convenience in that, but wonder if
> the runtime will do something that’s useful and widely applicable
> enough for that to translate directly into production code. What
> exactly does the runtime do if “lookup” fails here besides turn the
> outer function calls into no-ops?
The runtime doesn't do anything but error propagation. That's a plus in
my opinion, because it's simple to understand and efficient to
implement.
> Just guessing, but in many cases one would additionally want to log a
> warning and others where they even want to schedule the operation to
> retry at a later time. i.e. the treatment of the failure varies with
> the context. Is this type of composition flexible enough for that?
It's up to the user to check the result variable (here: r) and decide
what to do: abort, retry, continue, or report an error. Based on what
constitutes a self-contained unit in an algorithm, there are natural
points where one would try again. In the above example, perhaps at the
granularity of that put-test-lookup chain. To try again after a timeout,
I would imagine it as follows:
local algorithm = function() : result {
return put(store, key, test(lookup(store, key))) &timeout = 3 sec;
};
local r = result();
do {
r = algorithm();
} while (r?$error && r$error == timeout);
Based on how flexible we design the type in r$error, it can represent
all sorts of errors. The runtime could abort for critical errors, but
give control back to the user when it's a recoverable one.
Matthias
More information about the bro-dev
mailing list