> On Dec 14, 2016, at 9:27 AM, Robin Sommer wrote:
>
> 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
> On Dec 13, 2016, at 11:42 AM, Matthias Vallentin wrote:
>
>>> local r = put(store, key, test(lookup(store, key)));
>
> 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.
The thing that got me
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:
On Wed, Dec 14, 2016 at 14:44 +, you wrote:
> Would that mean you wouldn't be able to return a bool and check for
> errors at the same time?
No, it would always return an opaque ("opaque of Broker::Data" in this
case). If you used that in a boolean context, it would evaluate to the
error
> On Dec 13, 2016, at 1:52 PM, Robin Sommer wrote:
>
> My draft proposal extends
> opaque types to support conversion to boolean to allow for more
> elegant error checks.
Would that mean you wouldn't be able to return a bool and check for errors at
the same time?
--
- Justin
> On Dec 13, 2016, at 2:51 PM, Matthias Vallentin wrote:
>
>> Maybe the conversion to bool that I proposed originally should really
>> be a conversion to a dedicated error type, so that one can
>> differentiate what happened.
>
> I like that.
I like that too. Having