[
https://issues.apache.org/jira/browse/FLINK-24924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17444522#comment-17444522
]
Marios Trivyzas commented on FLINK-24924:
-----------------------------------------
I'm definitely +1 to throw exceptions by default for all such methods (which
means for all those utility methods implementing the functionality).
If we silently return null, then we could detect an error: if the input was
non-null but the output is null, then an error occurred, but we loose any
details about the error happened and we can only return a generic error.
If we throw exception in the first place, then it's much easier to catch the
exception and return null, if that's preferred, or simply propagate/wrap the
exception and still have nice details of what went wrong.
Especially for this case of DATE/TIME/TIMESTAMP it's very helpful to have a
detail error and see where and why the parsing broke.
> TO_TIMESTAMP and TO_DATE should fail
> ------------------------------------
>
> Key: FLINK-24924
> URL: https://issues.apache.org/jira/browse/FLINK-24924
> Project: Flink
> Issue Type: Sub-task
> Reporter: Francesco Guardiani
> Priority: Major
>
> In a similar fashion to what described
> https://issues.apache.org/jira/browse/FLINK-24385, TO_TIMESTAMP and TO_DATE
> should fail instead of returning {{null}}.
> In particular for these two functions, a failure in parsing could lead to
> very unexpected behavior, for example it could lead to records with null
> rowtime.
> We should change these functions to fail by default when parsing generates an
> error. We can let users handle errors by letting them use TRY_CAST for the
> same functionality:
> {code:sql}
> -- This fails when input is invalid
> TO_TIMESTAMP(input)
> -- Behaves the same as above
> CAST(input AS TIMESTAMP)
> -- This returns null when input is invalid
> TRY_CAST(input AS TIMESTAMP)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
