Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

[William Chan (陈智昌) <[e-mail]>]

On Wed, Jun 19, 2013 at 10:58 AM, Martin Thomson
<[e-mail]>wrote:

> On 19 June 2013 10:28, William Chan (陈智昌) <[e-mail]> wrote:
> > Actionable difference: it tells you what part of your stack to debug.
> > PROTOCOL_ERROR is terrible :( Everytime we generate a PROTOCOL_ERROR, we
> > have felt we wanted to add a debug string (that opaque byte sequence we
> > discussed earlier) so we could figure out what was wrong.
>
> I thought that was the reason you wanted to put the opaque stuff in the
> body.
>

Kinda. Btw, my earlier answer (which I now realize is slightly wrong, since
it really applied to INTERNAL_ERROR) was just to say that it does have an
actionable difference, and that generic error codes without debug strings
suck. I don't really mind as long as we have the opaque bytes. Here would
be my high level points on this topic.

* Error codes are insufficient. There are an infinite number of possible
errors that could happen at a different layer that it would be nice to have
opaque bytes for (e.g. reverse proxy INTERNAL_ERROR, where errors come from
the proxy's backend).
* Error codes are nice if you're going to have automated handling of
certain error codes. I don't believe that applies here.
* Error codes are also nice if you need to standardize a way for one
endpoint to inform the other endpoint of its error. INTERNAL_ERROR with
debug strings works fine when the receiver of the error code and opaque
bytes can just send the opaque bytes out of band back to the original
sender. But a PROTOCOL_ERROR is a way for the error code sender to tell the
receiver that it was Doing It Wrong. So an opaque explanation here doesn't
do much. A finer grained error code might be helpful.


>
> The reason I'm pushing back is that it is possible to spend error code
> bits on any amount of subdivision of the PROTOCOL_ERROR space.  Do you
> want one for the case where someone didn't echo the bytes of a PING?
> Or when they decide to send something else rather than continuing a
> HEADERS block?  Or any of the many current and future
> your-implementation-is-broken cases?  Ultimately, this just leads to a
> blowout in error codes, to no good end.
>

Reasonable position and I don't really care. Just wanted to explain the
"actionable difference".