I think its not too late to reserve a set of error codes (200-299?) for "non-error" codes.
It won't be backward compatible (i.e. clients that currently do "else throw" will throw on non-errors), but perhaps its worthwhile. On Mon, Mar 16, 2015 at 9:42 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > Hey Jun, > > I'd really really really like to avoid that. Having just spent a bunch of > time on the clients, using the error codes to encode other information > about the response is super dangerous. The error handling is one of the > hardest parts of the client (Guozhang chime in here). > > Generally the error handling looks like > if(error == none) > // good, process the request > else if(error == KNOWN_ERROR_1) > // handle known error 1 > else if(error == KNOWN_ERROR_2) > // handle known error 2 > else > throw Errors.forCode(error).exception(); // or some other default > behavior > > This works because we have a convention that and error is something that > prevented your getting the response so the default handling case is sane > and forward compatible. It is tempting to use the error code to convey > information in the success case. For example we could use error codes to > encode whether quotas were enforced, whether the request was served out of > cache, whether the stock market is up today, or whatever. The problem is > that since these are not errors as far as the client is concerned it should > not throw an exception but process the response, but now we created an > explicit requirement that that error be handled explicitly since it is > different. I really think that this kind of information is not an error, it > is just information, and if we want it in the response we should do the > right thing and add a new field to the response. > > I think you saw the Samza bug that was literally an example of this > happening and leading to an infinite retry loop. > > Further more I really want to emphasize that hitting your quota in the > design that Adi has proposed is actually not an error condition at all. It > is totally reasonable in any bootstrap situation to intentionally want to > run at the limit the system imposes on you. > > -Jay > > > > On Mon, Mar 16, 2015 at 4:27 PM, Jun Rao <j...@confluent.io> wrote: > >> It's probably useful for a client to know whether its requests are >> throttled or not (e.g., for monitoring and alerting). From that >> perspective, option B (delay the requests and return an error) seems >> better. >> >> Thanks, >> >> Jun >> >> On Wed, Mar 4, 2015 at 3:51 PM, Aditya Auradkar < >> aaurad...@linkedin.com.invalid> wrote: >> >> > Posted a KIP for quotas in kafka. >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-13+-+Quotas >> > >> > Appreciate any feedback. >> > >> > Aditya >> > >>
