Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Currently, the interfaces of state accessing (e.g. ValueState#value ) claim to throw exceptions in their signatures. However, there are several issues in it:

1. The exception types thrown by each interface are inconsistent. While most of the interfaces claim to throw Exception , the interfaces of ValueState  throw IOException , and the State#clear()  never throw an exception. This can be confusing for users.
2. The use of Exception  or IOException  as the thrown exception type is too generic and lacks specificity.
3. Since the KeyedProcessFunction#processElement  throws Exception  already, users typically do not try to catch the exception thrown by state-accessing methods. Moreover, they may not be able to handle these exceptions. In cases where an exception occurs while accessing state, the job should fail. This aligns more with the characteristic of unchecked exceptions.

I believe it would be better for Flink state to adopt the approach used in the definition of Java collection interfaces, which do not throw any checked exceptions. Additionally, there have been previous discussions about eliminating all thrown exceptions in state-related interfaces and instead providing more specific unchecked exceptions in implementations (as mentioned in Stephan Ewen's comments). Therefore, this FLIP takes these ideas into account and proposes to reorganize the state-related exceptions in a more specific and clear way.

Proposed Changes & Public Interfaces

This FLIP proposes a change to the state API that is annotated as @PublicEvolving and targets version 2.0 . The main changes are:

        1. Remove all the Exception  and IOException  in signature of state-accessing interfaces

        2. Introduce sub-classes of FlinkRuntimeException  for different errors. The class diagram is like:

FlinkRuntimeException --- StateException --- StateTransformationException

                                                                           |- StateAccessException -- StateIOException

                                                                           |- StateSerializationException

More sub-classes will be added as needed.

         3. Modify all the related implementation of state interfaces accordingly.

Implementation Plan

The implementation will involve three steps.

• Step 1: New types of exceptions will be introduced.
• Step 2: The implementations of state-related interfaces will throw the newly introduced exceptions.
• Step 3: All old checked exceptions will be removed from the interfaces.

Compatibility, Deprecation, and Migration Plan

Since the signature of the public state API has changed, user code that uses these APIs needs to be recompiled. Additionally, if users have caught checked exceptions (such as IOException ) in their code, they will need to modify their code accordingly. Otherwise, recompilation alone should be sufficient.

Test Plan

Some tests checking if the new types of exception are thrown will be added.

Rejected Alternatives

Targeted at version 1.19 or 1.20.