> 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