> Could we then now also lift the error() method into the message class?
> So "if (msg.error())" would be a shortcut for
> "if(msg.status().error()? (And then we'd back be where we started I
> believe. :-)
Done.
And yes, we've done the full circle. ;-) But at least we're in full
agreement now. Sometimes converging takes a little longer.
> Btw, there's one more complexity with all this: when one gets a
> status, one cannot tell which operation it belongs to, as it depends
> on how thing got queued and processed internally. That can make it
> hard to react to something more specifically. But that's something we
> can't avoid with the asynchronous processing.
I think we can address this. First, the status code tells roughly what
went wrong. Second, a status has a context<T>() method that returns
additional information when available. For example, all peering-related
statuses include a broker::endpoint_info instance to figure out exactly
what peer created the issue. If we need the fine granularity, all we
need is to add the necessary context information. (This is enforced at
compile time, by the way; for a given status code, the context is either
a T or not present, but not of a different type.)
Matthias
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
