Page History

...

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.

...

        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

...

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.

...