> 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
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
