Add fallible versions of temporal functions that may panic#7737
Add fallible versions of temporal functions that may panic#7737alamb merged 4 commits intoapache:mainfrom
Conversation
arrow-arith/src/numeric.rs
Outdated
There was a problem hiding this comment.
I felt that it was better to just break this trait than introduce all of the new methods. It should be pretty easy for users to update the trait implementation itself, and it's always possible for them to just .expect(...) in their code to at least acknowledge the fallibility
There was a problem hiding this comment.
I double checked that this is not a public trait and thus this change is not a breaking API change
|
🤖 |
alamb
left a comment
There was a problem hiding this comment.
Thanks @adriangb -- this looks good to me -- I have kicked off some performance tests just to verify this doesn't change anything
I do think we should try and add some tests to this ideally showing that we can now catch overflows as errors rather than panics. Would you have time to do that?
arrow-arith/src/numeric.rs
Outdated
There was a problem hiding this comment.
I double checked that this is not a public trait and thus this change is not a breaking API change
|
Additional context is we hit this panic in DataFusion (and found a workaround) |
Yes I think I should have time in the next couple days! |
|
🤖: Benchmark completed Details
|
|
🤖 |
|
🤖: Benchmark completed Details
|
…panic due to overflows
3659a9e to
897fec6
Compare
|
@alamb I've added quite a bit of tests |
|
@alamb I don't have commit rights here, could you merge this if you think it's ready? thanks! |
# Which issue does this PR close? This PR does the same thing as what was done in #7737 to handle overflow errors gracely instead of panicking. - Part of #4456. # Rationale for this change <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> # What changes are included in this PR? <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> # Are these changes tested? yes # Are there any user-facing changes? <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. If there are any breaking changes to public APIs, please call them out. -->
Uh oh!
There was an error while loading. Please reload this page.