Hi Zakelly, Thanks for the FLIP. In the FLIP, it's stated "Since the signature of the public state API has changed, user code that uses these APIs needs to be recompiled". Is this FLIP proposing to change signatures of APIs annotated as @Public and therefore targeting Flink 2.0, or is it different? It would be great to get that clarified in the FLIP.
Best regards, Martijn On Wed, Sep 20, 2023 at 6:36 AM Yanfei Lei <fredia...@gmail.com> wrote: > > Hi Zakelly, > > Thanks for bringing this up. +1 for reorganizing. > > IIUC, this proposal aims to change all state-related exceptions to > unchecked exceptions. If users have caught checked exceptions (such as > IOException ) in their code, leaving the code as is would also work. > > Is it possible not to put any exceptions in the signature of > user-facing interfaces? As the proposal mentioned, users can do a few > things even if they catch the exceptions. Keeping the interface simple > may be easier to understand. > > > Best, > Yanfei > > Hangxiang Yu <master...@gmail.com> 于2023年9月19日周二 18:16写道： > > > > Hi, Zakelly. > > > > Thanks for the proposal. > > > > +1 for reorganizing exceptions of state interfaces which indeed confuses me > > currently. > > > > From my experience, users usually omit these exceptions because they cannot > > do much even if they catch the exceptions. > > > > I have some problems and suggestions, PTAL: > > > > 1. Could we also reorganize or add more state exceptions (may be related > > to other state interfaces/classes e.g. KeyedStateBackend) into the > > exception class diagrams ? Although these state-related classes may not > > be public, it could be better to consider them together to make all > > state-related exceptions clear. For example, we could reorganize some > > existing exceptions such as StateMigrationException, add some exceptions > > such as StateNotFoundException. > > 2. Could you clarify or give an example about the extended relation > > "StateAccessException -- StateIOException" ? When do we just return > > StateAccessException instead of StateIOException or others ? > > 3. Which version do you want to implement it in ? Since it has to break > > changes for users who have catched the IOException, If we want to > > implement > > it in 1.19, we must mark it very clearly in the release note, or we > > should > > make it in 2.0. > > > > > > On Tue, Sep 19, 2023 at 5:08 PM Zakelly Lan <zakelly....@gmail.com> wrote: > > > > > Hi everyone, > > > > > > I would like to initiate a discussion on FLIP-368, which focuses on > > > reorganizing the exceptions thrown in state interfaces [1]. > > > > > > Currently, we have identified several problems with the exceptions > > > thrown by state-related interfaces: > > > 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`. Additionally, the > > > `State#clear()` never throws 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. Users 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* instead > > > of checked exceptions. > > > > > > To address these issues, we borrow the idea of throwing unchecked > > > exceptions in Java Collection API and propose the following changes in > > > state-related exceptions: > > > 1. Introduction of specific unchecked exception types for different > > > reasons, providing users with more precise information about the cause > > > of the exception. > > > 2. Removal of all checked exceptions from interface signatures and > > > instead, throwing newly introduced unchecked exceptions in the > > > implementations. > > > > > > Please share your thoughts and suggestions regarding the proposed > > > changes. Thank you for your attention and support. > > > > > > > > > Best, > > > Zakelly > > > > > > [1] FLIP-368: Reorganize the exceptions thrown in state interfaces, > > > https://cwiki.apache.org/confluence/x/eZ2zDw > > > > > > > > > -- > > Best, > > Hangxiang.
