C0urante commented on PR #14721: URL: https://github.com/apache/kafka/pull/14721#issuecomment-1804121753
I realize that. I think preserving the existing exception type is more valuable (and correct) here. We'd also be dropping the stack trace for the top-level exception (see [ApiException::fillInStackTrace](https://github.com/apache/kafka/blob/39c6170aa96e4c9840ac469d1b43bb059f0513af/clients/src/main/java/org/apache/kafka/common/errors/ApiException.java#L45-L49)) if we switched to using `InvalidConfigurationException`. If we really want to preserve all information (including stack traces for the exception and its cause), we should use an exception type that doesn't subclass `ApiException`. IMO it's not worth it to switch to a third thing, though, and it's better to preserve the top-level exception's stack trace than the cause's stack trace. If absolutely necessary, we can manually construct the caused-by string in the message we pass to `ConfigException`, in addition to the message of the cause (and possibly the type, now that I think about it). But I don't think that's necessary here and it strikes me as overkill. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
