gt; > >
> > > > > But "Since the signature of the public state API has been changed",
> > I was
> > > > > wondering whether this would be more fittable in Flink 2.0, instead
> > of
> > > > 1.19?
> > > >
On balance, as I am risk averse, I would suggest delaying this to v2 as
> Jing has proposed. This is a cleaner API, is there a demand for this in a
> dot version? If the community think this is too risk averse, then we could
> go with 1.19.
> > WDYT?
> >
> > Kind regard
m: Jing Ge
> Date: Friday, 13 October 2023 at 14:30
> To: dev@flink.apache.org
> Subject: [EXTERNAL] Re: FW: RE: [DISCUSS] FLIP-368 Reorganize the exceptions
> thrown in state interfaces
> HI Zakelly,
>
> What about the jobs that catch those exceptions? Will these downstream
&
Date: Friday, 13 October 2023 at 14:30
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: FW: RE: [DISCUSS] FLIP-368 Reorganize the exceptions
thrown in state interfaces
HI Zakelly,
What about the jobs that catch those exceptions? Will these downstream
callers that expect this exception to be
; > throws around the existing checked Exceptions.
> > > >
> > > > If we go with RunTimeException, I would suggest that this sort of
> > > breaking change should be done on a Flink version change, where it is
> > > appropriate to make breaking changes to the API with as
hould not be trying to create code now for an implementation
> > consideration that is not there yet,
> >
> > +1 from me ,
> > Kind regards, David.
> >
> > From: Zakelly Lan
> > Date: Wednesday, 11 October 2023 at 04:25
> > To: dev@flink.apache.org
&
To: dev@flink.apache.org
> Subject: [EXTERNAL] Re: FW: RE: [DISCUSS] FLIP-368 Reorganize the
> exceptions thrown in state interfaces
> Hi David,
>
> Thanks for your response.
>
> The exceptions thrown by state interfaces are NOT retriable. For
> example, there may be some el
Subject: [EXTERNAL] Re: FW: RE: [DISCUSS] FLIP-368 Reorganize the exceptions
thrown in state interfaces
Hi David,
Thanks for your response.
The exceptions thrown by state interfaces are NOT retriable. For
example, there may be some elements sent to the wrong subtask due to a
non-deterministic hashCode
k?
> Kind regards, David.
>
>
> From: David Radley
> Date: Tuesday, 10 October 2023 at 09:49
> To: dev@flink.apache.org
> Subject: [EXTERNAL] RE: [DISCUSS] FLIP-368 Reorganize the exceptions thrown
> in state interfaces
> Hi ,
> The argument seems to be that the
: Tuesday, 10 October 2023 at 09:49
To: dev@flink.apache.org
Subject: [EXTERNAL] RE: [DISCUSS] FLIP-368 Reorganize the exceptions thrown in
state interfaces
Hi ,
The argument seems to be that the errors cannot be acted on so should be
runtime exceptions. I want to confirm that none of these errors
October 2023 at 18:12
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: [DISCUSS] FLIP-368 Reorganize the exceptions thrown in
state interfaces
Hi everyone,
It seems we're gradually reaching a consensus. So I would like to
start a vote after 72 hours if there are no further discussions.
P
Hi everyone,
It seems we're gradually reaching a consensus. So I would like to
start a vote after 72 hours if there are no further discussions.
Please let me know if you have any concerns, thanks!
Best,
Zakelly
On Sat, Oct 7, 2023 at 4:07 PM Zakelly Lan wrote:
>
> Hi Jing,
>
> Sorry for the
Hi Jing,
Sorry for the late reply! I agree with you that we do not expect users
to do anything with Flink and we won't "bother" them with those
exceptions. However, users can still catch the `Throwable` and perform
any necessary logging activities, similar to how they use Java
Collection interface
Fair enough! Thanks Zakelly for the information. Afaic, even users can do
nothing with Flink, they still can do something in their territory, at
least doing some logging and metrics stuff, or triggering some other
services in their ecosystem. After all, the Flink jobs they build are part
of their s
Hi Martijn,
Thanks for the reminder!
This FLIP proposes a change to the state API that is annotated as
@PublicEvolving and targets version 1.19. I have clarified this in
the "Proposed Change" section of the FLIP.
Hi Jing,
Thanks for sharing your thoughts! Here are my opinions:
1. The excepti
sorry, typo: It is a known "anti-pattern" instead of "ant-pattern"
Best regards,
Jing
On Wed, Sep 20, 2023 at 7:23 PM Jing Ge wrote:
> Hi Zakelly,
>
> Thanks for driving this topic. From good software engineering's
> perspective, I have different thoughts:
>
> 1. The idea to get rid of all chec
Hi Zakelly,
Thanks for driving this topic. From good software engineering's
perspective, I have different thoughts:
1. The idea to get rid of all checked Exceptions and replace them with
unchecked Exceptions is a known ant-pattern: "Generally speaking, do not
throw a RuntimeException or create a
Hi Yanfei,
Thanks for your reply!
Yes, this FLIP aims to change all state-related exceptions to
unchecked exceptions and remove all exceptions from the signature. So
I believe we have come to an agreement to keep the interfaces simple.
Best regards,
Zakelly
On Wed, Sep 20, 2023 at 2:26 PM Zake
Hi Hangxiang,
Thank you for your response! Here are my thoughts:
1. Regarding the exceptions thrown by internal interfaces, I suggest
keeping them as checked exceptions. Since these exceptions will be
handled by the internal callers, it is meaningful to throw them as
checked ones. If we need to m
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
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 a
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.
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
23 matches
Mail list logo
