[
https://issues.apache.org/jira/browse/KAFKA-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970583#comment-16970583
]
Guozhang Wang commented on KAFKA-7016:
--------------------------------------
I think I also agree with this change, primarily driven by all of my debugging
experience on Kafka Consumer: each time I would want to comment out the
``fillInStackTrace`` in my local branch, and then upon submitting the PR I'd
need to revert that change again. I think it is actually worth printing the
stack trace when ApiException is thrown because it is usually considered a
fatal error which causes the client to be shutdown / restart anyways so being a
bit costly would not hurt much.
> Reconsider the "avoid the expensive and useless stack trace for api
> exceptions" practice
> ----------------------------------------------------------------------------------------
>
> Key: KAFKA-7016
> URL: https://issues.apache.org/jira/browse/KAFKA-7016
> Project: Kafka
> Issue Type: Bug
> Reporter: Martin Vysny
> Priority: Major
>
> I am trying to write a Kafka Consumer; upon running it only prints out:
> {\{ org.apache.kafka.common.errors.InvalidGroupIdException: The configured
> groupId is invalid}}
> Note that the stack trace is missing, so that I have no information which
> part of my code is bad and need fixing; I also have no information which
> Kafka Client method has been called. Upon closer examination I found this in
> ApiException:
>
> {{/* avoid the expensive and useless stack trace for api exceptions */}}
> {{@Override}}
> {{public Throwable fillInStackTrace() {}}
> \{{ return this;}}
> {{}}}
>
> I think it is a bad practice to hide all useful debugging info and trade it
> for dubious performance gains. Exceptions are for exceptional code flow which
> are allowed to be slow.
>
> This applies to kafka-clients 1.1.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
