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 ```Exception```s. 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

The main changes are:

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

        2. Introduce sub-classes of ```FlinkRuntimeException``` to represent different exceptions. 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. Firstly, new types of exceptions will be introduced. Secondly, the implementations of state-related interfaces will throw the newly introduced exceptions. Lastly, 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

None for now.