[ 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)