...

Currently only some exceptions that occur during processing are wrapped as a StreamsException , which complicates before being handed up to the uncaught exception handler. Unfortunately we don't make any guarantees about which exceptions will or will not be wrapped as a StreamException, which  complicates the logic required by a user custom StreamsUncaughtExceptionHandle's custom exception handler and makes it difficult to enforce any kind of compatibility.

r. It would be cleaner to ensure that all exceptions thrown to the user/handler are wrapped (exactly once) as a StreamsException. Further, many exceptions can be traced back to a particular task that's experiencing an error specific to that part of the topology, or that partition, etc. It can be helpful to have that information when determining how to handle the exception, as well as for debugging purposes. We propose to add a TaskId field to the StreamsException class to help users identify the source of an exception.

...

Proposed Changes

This KIP proposes to

1. Make sure Guarantee that every exception that is thrown up to the uncaught exception handler, whether that be the new StreamsUncaughtExceptionHandler or the old generic UncaughtExceptionHandler, is wrapped as a StreamsException.
2. Add a new TaskId field to the StreamsException class, with a getter API to expose it. This field will be set for any exception that originates from, or is tied to, a specific task. For example:
   1. Task timeout (ie exceeds the configured task.timeout.ms value
   2. User processing error or other exception thrown from Task#process
   3. Exceptions arising from task management, such as suspending/closing/flushing/etc 

...

Compatibility, Deprecation, and Migration Plan

N/A – just adding a new APITheoretically, a user could have some logic in their exception handlers that check the specific type of the throwable, and act upon it accordingly – for example, if it's a TimeoutException, then they opt to replace the thread. After this KIP, all exceptions will be of the type StreamsException, and this logic would break. However, since we currently make no guarantee that a TimeoutException (or any exception for that matter) will or will not be wrapped as a StreamsException, a user would in fact already need to consider this and check the throwable to determine if it needs to be unwrapped first. This case is actually what this KIP is trying to improve, by giving users a guarantee that they will always be receiving an exception of type StreamsException, and will need to check it for a cause before determining how to react.

Rejected Alternatives

None