[
https://issues.apache.org/jira/browse/KAFKA-13978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558320#comment-17558320
]
A. Sophie Blee-Goldman commented on KAFKA-13978:
------------------------------------------------
Yeah we've discussed this a bit and personally, I agree that we should revert
that commit at least until we can do a better job of classifying/identifying
exceptions. Maybe in the long term we would want to, for example, not allow the
user to opt to replace the thread/continue processing if the exception is known
to be fatal, or corrupting data, etc – but we don't have that kind of error
parsing in place right now, so it doesn't make sense to just unilaterally
consider all IllegalState/IllegalArgument exceptions as fatal (and even if they
are, we should still invoke the handler to notify the user)
> Trigger UncaughtExceptionHandler for IllegalArgument and IllegalState
> exceptions
> --------------------------------------------------------------------------------
>
> Key: KAFKA-13978
> URL: https://issues.apache.org/jira/browse/KAFKA-13978
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 3.1.0, 3.2.0, 3.1.1
> Reporter: Ben
> Priority: Major
>
> In [KAFKA-12887|https://issues.apache.org/jira/browse/KAFKA-12887]
> [(PR)|https://github.com/apache/kafka/pull/11228/files] changes were made to
> prevent thrown IllegalStateException and IllegalArgumentExceptions from being
> passed to a registered exception handler.
>
> I believe these changes should be reverted for the following reasons:
> * Making this change is backwards incompatible with existing applications
> which may have expected those exceptions to be handled.
>
> * Users can (and do!) throw these exceptions, often for legitimate reasons.
> For instance, IllegalArgumentException is thrown when a method is passed the
> wrong argument. This is exactly the type of uncaught exception a user would
> expect to be handled by the uncaught exception handler, rather than by the
> calling code.
>
> * The change is inconsistent. Why only these two exceptions, and not all
> runtime exceptions?
>
> * The change is not well documented. There are even tutorial resources which
> actually use these exceptions, [for example
> here|https://developer.confluent.io/tutorials/error-handling/confluent.html].
> If we make this change, it should be better communicated. As implemented, it
> is extremely surprising that this happens.
>
> * Finally, what value is the change actually adding to the project? It
> restricts user freedom, increases complexity, and does not improve safety. We
> should only make a backwards-incompatible change like this if there is clear
> value in doing so.
>
> As a note, reverting this is not (in my view) going to impact users
> negatively. It is unlikely many people depend on this functionality, and if
> they do, it should be easy to communicate in the release notes, and for them
> to adjust their code accordingly.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
