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.
