[
https://issues.apache.org/jira/browse/KAFKA-10830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303865#comment-17303865
]
Dongjin Lee commented on KAFKA-10830:
-------------------------------------
[~guozhang] [~bchen225242] I inspected this problem (yes, I have also suffered
from this 'turtles all the way down' exceptions) and have an idea:
# If KafkaException is directly instantiated and the given cause is also (a
kind of) KafkaException, skip the instantiation. (i.e., returns the cause
instance.)
# If a child class is instantiated and given cause is (a kind of)
KafkaException, skip the direct cause. (i.e., instantiate with the cause of
cause instance.)
Do you think this strategy is reasonable? If then, I will open a PR.
> Kafka Producer API should throw unwrapped exceptions
> ----------------------------------------------------
>
> Key: KAFKA-10830
> URL: https://issues.apache.org/jira/browse/KAFKA-10830
> Project: Kafka
> Issue Type: Improvement
> Components: producer
> Reporter: Guozhang Wang
> Priority: Major
>
> Today in various KafkaProducer APIs (especially send and transaction related)
> we wrap many of the underlying exception with a KafkaException. In some
> nested calls we may even wrap it more than once. Although the initial goal is
> to not expose the root cause directly to users, it also brings confusion to
> advanced user's error handling that some KafkaException wrapped root cause
> may be handled differently.
> Since all of those exceptions are public classes anyways (since one can still
> get them via exception.root()) and they are all inheriting KafkaException,
> I'd suggest we do not do any wrapping any more and throw the exception
> directly. For those users who just capture all KafkaException and handle them
> universally it is still compatible; but for those users who want to handle
> exceptions differently it would introduce an easier way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
