Sounds good to me.
-Jay
On Thu, Feb 13, 2014 at 1:28 PM, Guozhang Wang wrote:
> OK, unless someone else is against the second option I will change the code
> accordingly.
>
>
> On Thu, Feb 13, 2014 at 10:15 AM, Jay Kreps wrote:
>
> > Yeah I agree, I think we just have to be very careful that
OK, unless someone else is against the second option I will change the code
accordingly.
On Thu, Feb 13, 2014 at 10:15 AM, Jay Kreps wrote:
> Yeah I agree, I think we just have to be very careful that the right errors
> are thrown versus stuffed in the future.
>
> -Jay
>
>
> On Thu, Feb 13, 201
Yeah I agree, I think we just have to be very careful that the right errors
are thrown versus stuffed in the future.
-Jay
On Thu, Feb 13, 2014 at 9:24 AM, Neha Narkhede wrote:
> Alternately we could throw user errors from send. These you wouldn't need
> to catch because they should not happen (
Alternately we could throw user errors from send. These you wouldn't need
to catch because they should not happen (and if they do it is a bug, not
something you should really catch and handle). The only concern here is
that we have to be very careful to ensure we categorize each exception
correctly
Some context on this.
Originally (i.e. in the first patch) I threw any exception I could
including all class B exceptions directly from the send() call and only
threw api exceptions with the future. My concern with this approach was
just the complexity of the error handling. You end up needing to
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 s
