...

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

...

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``` Exception , the interfaces of ```ValueState``` ValueState  throw ```IOException``` IOException , and the ```State#clearState#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``` KeyedProcessFunction#processElement  throws ```Exception``` 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 ```Exception```schecked 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``` Exception  and ```IOException``` IOException  in signature of state-accessing interfaces

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

FlinkRuntimeException --- StateException --- StateTransformationException

                                                                           |- StateAccessException -- StateIOException

                                                                           |- StateSerializationException

...

The implementation will involve three steps. Firstly, new

• 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``` IOException ) in their code, they will need to modify their code accordingly. Otherwise, recompilation alone should be sufficient.

...

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

Rejected Alternatives

None for nowTargeted at version 1.19 or 1.20.