Folks, While working on the new producer, I noticed another issue about error handling that I would like to ask for some discussions (I know Jay said the protocol definition is the last one, but I guess that can never be true :)
Currently we have two classes of exceptions that we can throw when sending messages with the producer, class A is more operational related and recoverable, such as: 1. Producer buffer full with BLOCK_ON_BUFFER_FULL set to false. 2. Message size too large. 3. Timed out on produce requests. 4. Error responses from brokers. etc Class B is more related to client app bugs and fatal, such as: 1. Invalid specified partition Id. 2. Calling send() after close(). 3. Send a message with topic as null. etc We have two options to throw them: either we wrap all exceptions in the returned future which will then only throw the exception if you call future.get(), and the send() call will not expect any checked exceptions; or we wrap class A exceptions in future and directly throw class B exceptions in send() call. The pros of the first option is that you only need to try/catch the future.get call if you care enough to check these errors, the cons is that if your async producer does not care about class A but only want to check class B errors, you still need to block wait on get() for all messages. And vice versa for the other option. Thoughts? -- -- Guozhang
