Hi Timo, That makes sense, and thanks for driving this. Infrastructure first is the right order, and a pass spanning releases sounds realistic for the scope.
Looking forward to seeing the skeleton land. Best regards, Sepuri Sai Krishna On Wed, Nov 4, 2026 at 8:10 PM Timo Walther via dev <[email protected]> wrote: > Hi Krishna, > > just to set expectations right: This FLIP introduces the infrastructure > for improving our error messages going forward. Once we come up with a > solid skeleton, with the help of AI we will definitely make a pass over > all existing exceptions. This includes CodeGenException. I don't want to > give guarantees at this stage, because it is a large effort that might > span multiple Flink releases. But the examples that you listed are > exactly the type of issues we want to tackle. > > Cheers, > Timo > > > On 04.11.26 14:51, Krishna Sai wrote: > > Hi Timo, > > > > This would help a lot, in particular putting the category on the error > > rather than on the exception class. > > > > One measured example, if a second family is useful. In batch, a MAP is > > rejected at every comparison site I tried, through three different > > exception classes: > > > > ORDER BY m and GROUP BY m both give ValidationException, "Type > 'MAP<STRING, > > INT> NOT NULL' cannot be ordered, so it cannot be used as a key for > > sorting, grouping, or joining". One template serves both, so a grouping > > failure reads as an ordering one. > > > > MIN(m) gives TableException wrapping TableException, "Cannot generate a > > valid execution plan for the given query: Min aggregate function does not > > support type: ''MAP''." The outer text names plan generation rather than > > the mistake, which is your second motivation. > > > > l.m < r.m gives CodeGenException, "Comparable type expected, but was > > 'MAP<STRING, INT> NOT NULL'." > > > > One scope question. CodeGenException extends RuntimeException directly > and > > carries no stability annotation, so the reparenting in the FLIP would not > > reach it, and it arrives as the top level exception rather than a cause. > Is > > it a later family, or worth reparenting with the others while that is > open? > > > > For the message guidelines: the ''MAP'' is literal, from ten sites in > > AggFunctionFactory of the form s"... type: ''$t''...". Harmless, but the > > sort of thing guidelines would settle. > > > > Glad to help if useful. > > > > Best regards, > > Sepuri Sai Krishna > > > > On Wed, Nov 4, 2026 at 3:57 PM Timo Walther via dev < > [email protected]> > > wrote: > > > >> Hi everyone, > >> > >> I would like to start a discussion about FLIP-620: Structured errors for > >> Table API and SQL. > >> > >> > >> > https://cwiki.apache.org/confluence/spaces/FLINK/pages/462815815/FLIP-620+Structured+errors+for+Table+API+and+SQL > >> > >> Flink is increasingly embedded in larger platforms, SQL gateways, > >> notebooks, IDEs and AI agents. All of them need to understand why a job > >> or statement failed. Today, errors are mostly free-form messages. If you > >> want to react to a specific failure, you have to parse text, and that > >> text can change in any release. This makes it hard to tell user mistakes > >> from internal problems, to attach stable error codes, to show a helpful > >> message for a given audience, or to avoid leaking sensitive values into > >> logs. > >> > >> Other database systems treat errors as part of their public contract. > >> They have stable identifiers, categories and SQLSTATE codes, and the > >> message is only one rendering of an error. > >> > >> FLIP-620 proposes a small, backwards-compatible foundation: errors that > >> have an identity, a category and structured arguments, so that tools can > >> catch, classify and present them reliably. First I target Table API and > >> SQL but propose a common model that other Flink components can adopt > later. > >> > >> I'm looking forward to your feedback. > >> > >> Best, > >> Timo > >> > > > >
