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
