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 >
