On Wed, Sep 20, 2017 at 16:12 -0700, you wrote:
> What are your thoughts on error handling?
Good question, two parts to that.
First, along the lines of Justin's response, the function is free to
return whatever it considers the appropiate result for an error case.
The only constraint is that i
> On Sep 20, 2017, at 7:12 PM, Alan Commike wrote:
>
> What are your thoughts on error handling?
>
> Exec::run() returns an Exec::Result, which is nice in that we can recover if
> something goes wrong. I would think one would want most calls of Exec::run()
> in an async context, but we lose
What are your thoughts on error handling?
Exec::run() returns an Exec::Result, which is nice in that we can recover
if something goes wrong. I would think one would want most calls of
Exec::run() in an async context, but we lose the return value.
...alan
On Tue, Sep 19, 2017 at 9:39 AM, Robi
On Tue, Sep 19, 2017 at 17:32 +, you wrote:
> Understanding the new code also requires understanding the context in
> which it is implemented and I wonder if the later is more of a hurdle
> here.
Hey, this is bro-dev, are you saying not everybody here is intimately
familiar with the Bro sou
> On Sep 19, 2017, at 11:39 AM, Robin Sommer wrote:
>
> The exercise here is: Can you understand how "async" works? (If you
> can honestly answer "yes" in under 15 minutes, I buy you a beer. ;-)
A feat like that deserves a larger reward.
Understanding the new code also requires understanding
At BroCon a few folks asked me about the proposed "async" keyword for
Bro's scripting language. "async" is coroutine-style language
construct that puts blocking operations on hold until they conclude,
working on other stuff first. It could replace most uses of "when" and
is arguably much nicer to u
