[
https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Lonergan updated FLINK-14174:
----------------------------------
Description:
The change made by https://github.com/apache/flink/pull/4663/files introduces a
"helpful hint" that a class cast at that location might be due a Flink pipeline
cfg error and the code goes onto swallows the original exception and masked a
protocol buffer serialisation problem we were having.
This "helpful hint" is sometimes a complete red herring and in my case wasted a
lot of peoples time.
In my case I had a class cast error in some proto serialisation code and
because the "helpful hint" traps ClassCastException I wasn't able to discover
the error easily. In the end we modified the Flink distribution to remove this
"helpful hint" at which point the real error was found and we quickly fixed it
- but not without a lot of burned time.
I am not convinced of the cost/benefit of the "helpful hint" introduced by
FLINK-4663 for two reasons
- it can be a red herring - in mine case and also and [at least one other
person
|https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception
]
- I don't agree with ever throwing away or masking causal exceptions - these
must always be propagated (I raised a similar issue in my previous contribution)
----
My suggestion is to either back out FLINK-4663 so that we get to see the raw
underlying exception and call stack -or- come up with a way to distinguish the
specific case "FLINK-4663" was attempting to cover and only emit that hint hint
if the specific case is encountered.
For all other cases the helpful hint should not be emitted.
And - regardless of whether the helpful hint it emitted or not +the causal
exception must always be propagated+.
My vote is to back out FLINK-4663 and maybe add some logging instead.
was:
The change made by https://github.com/apache/flink/pull/4663/files introduces a
"helpful hint" that a class cast at that location might be due a Flink pipeline
cfg error and the code goes onto swallows the original exception and masked a
protocol buffer serialisation problem we were having.
This "helpful hint" is sometimes a complete red herring and in my case wasted a
lot of peoples time.
In my case I had a class cast error in some proto serialisation code and
because the "helpful hint" traps ClassCastException I wasn't able to discover
the error easily. In the end we modified the Flink distribution to remove this
"helpful hint" at which point the real error was found and we quickly fixed it
- but not without a lot of burned time.
I am not convinced of the cost/benefit of the "helpful hint" introduced by
FLINK-4663 for two reasons
- it can be a red herring - in mine case and also and [at least one other
person
|https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception
]
- I don't agree with ever throwing away or masking causal exceptions - these
must always be propagated (I raised a similar issue in my previous contribution)
----
My suggestion is to either back out FLINK-4663 so that we get to see the raw
underlying exception and call stack or come up with a way to distinguish the
specific case "FLINK-4663" was attempting to cover and only emit that hint hint
if the specific case is encountered.
For all other cases the helpful hint should not be emitted.
And - regardless of whether the helpful hint it emitted or not +the causal
exception must always be propagated+.
My vote is to back out FLINK-4663 and maybe add some logging instead.
> Don't swallow exception when rethrowing type mismatches with side outputs
> -------------------------------------------------------------------------
>
> Key: FLINK-14174
> URL: https://issues.apache.org/jira/browse/FLINK-14174
> Project: Flink
> Issue Type: Improvement
> Components: API / DataStream
> Affects Versions: 1.8.1, 1.9.0
> Reporter: John Lonergan
> Priority: Major
>
> The change made by https://github.com/apache/flink/pull/4663/files introduces
> a "helpful hint" that a class cast at that location might be due a Flink
> pipeline cfg error and the code goes onto swallows the original exception and
> masked a protocol buffer serialisation problem we were having.
> This "helpful hint" is sometimes a complete red herring and in my case wasted
> a lot of peoples time.
> In my case I had a class cast error in some proto serialisation code and
> because the "helpful hint" traps ClassCastException I wasn't able to discover
> the error easily. In the end we modified the Flink distribution to remove
> this "helpful hint" at which point the real error was found and we quickly
> fixed it - but not without a lot of burned time.
> I am not convinced of the cost/benefit of the "helpful hint" introduced by
> FLINK-4663 for two reasons
> - it can be a red herring - in mine case and also and [at least one other
> person
> |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception
> ]
> - I don't agree with ever throwing away or masking causal exceptions - these
> must always be propagated (I raised a similar issue in my previous
> contribution)
> ----
> My suggestion is to either back out FLINK-4663 so that we get to see the raw
> underlying exception and call stack -or- come up with a way to distinguish
> the specific case "FLINK-4663" was attempting to cover and only emit that
> hint hint if the specific case is encountered.
> For all other cases the helpful hint should not be emitted.
> And - regardless of whether the helpful hint it emitted or not +the causal
> exception must always be propagated+.
> My vote is to back out FLINK-4663 and maybe add some logging instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
