Proposal: Status Code Error Enums

[jasnell]

For errors, any negative value should be considered an error, with multiple negative values permitted. That would obviously mean not using an enum for status, and instead using constants... e.g.

#define BOB_ERR_{whatever} -{some integer}
#define BOB_ERR_END 0
#define BOB_ERR_CONTINUE 1

[jasnell]

Another suggestion tho it makes the protocol slightly more complicated. QUIC uses a nice pattern where errors can actually be namespaced. It allows us to avoid needing to reserve error ranges. For instance:

#define BOB_ERR_FAMILY_BOB 0  // Status codes common to all Bob cases
#define BOB_ERR_FAMILY_APP 1  // Status codes specific to the Bob application

#define BOB_ERR_FAIL -1
#define BOB_ERR_END 0
#define BOB_ERR_CONTINUE 1

struct BobError {
  int code;
  int family;
  BobError(
      int code_ = BOB_ERR_END,
      int family_ = BOB_ERR_FAMILY_BOB) :
      code(code_), family(family_) {}
};

// Usage
BobError error();
BobError error(BOB_ERR_CONTINUE);
BobError error(-100, BOB_ERR_FAMILY_APP);

Provides a bit more flexibility over time.

[Fishrock123]

@jasnell Can you elaborate on the purpose?

Keep in mind the actual error is a different property than the status. The Status determines specifically the flow, but any component could, once reading that the states was an error, do something different depending on what the error was?

[jasnell]

Well, I can illustrate by pointing to QUIC at least. With QUIC, there are generally three kinds of errors: Protocol, Crypto, and Application. The Crypto errors are a reserved range of Protocol errors so I'll ignore those for now. Simply, A protocol error with code -1 has different meaning that an application error with code -1; with the former being defined by the QUIC spec, and the latter being defined by the application spec (for instance HTTP/3). So, Protocol error -215 might be "Invalid QUIC Packet Format" while Application error -215 might be "Invalid HTTP Header format". The purpose of differentiating in bob would be to allow more granular error conditions to flow through the bob protocol rather than having to rely on additional out-of-band means for propagating.

[Fishrock123]

I suppose I mean more, how do you envision those being handled in a series of stream components?

[jasnell]

in the protocol, all errors are just pass-through terminal states. Rather than a single value propagating up, you have the pair propagating up. If there are any bob protocol specific actions to take, those would only be specific to the BOB_ERR_FAMILY_BOB errors.

[Fishrock123]

Hmmm, I'm not sure yet.

I think it would be good to design the system to be able to be expanded to such a use-case but perhaps not fully support it, at least in "early" iterations.