[Bro-Dev] Rethinking Broker's blocking API

Matthias Vallentin vallentin at icir.org
Tue Jan 10 09:38:47 PST 2017


> I see the challenge but I think we need some way to differentiate
> serious errors from expected updates, otherwise we're back at writing
> switch statements that need to comprehensively list all cases. 

I agree that writing switch statements is not very productive. From a
user perspective, it's important to distinguish whether I can ignore
a status update, or whether I have to react to it. I would consider more
fine-grained classifications arbitrary. In particular, I find 3 levels
too complex. Users will wonder "wait, was this an info or a warning?"
and then have to go back to the documentation.

How about making it explicit by providing two types of codes, status and
errors:

    enum class sc : uint8_t {
      unspecified = 1,
      peer_added,
      peer_removed,
      peer_recovered,
    };

    enum class ec : uint8_t {
      unspecified = 1,
      peer_incompatible,
      peer_invalid,
      peer_unavailable,
      peer_lost,
      peer_timeout,
      master_exists,
      no_such_master,
      ...
    };

This is close to the original design, except that the peer_* codes are
now split into errors and status, and that we still have a single status
class to combine them both:

    auto s = msg.status();
    if (s.error())
      // Compare against error codes for details.
    else
      // Compare against status codes for details.

Or simpler: avoiding the explicit distinction of error and status codes
and let the function status::error() return true for what we deem
actionable errors.

    Matthias


More information about the bro-dev mailing list