Remove redundant unwrap in ScalarValue::new_primitive, return a Result #7830
Remove redundant unwrap in ScalarValue::new_primitive, return a Result #7830Dandandan merged 1 commit intoapache:mainfrom
ScalarValue::new_primitive, return a Result #7830Conversation
maruschin
force-pushed
the
remove_redundant_unwrap
branch
10 times, most recently
from
291f741 to
6de516d
Compare
maruschin
changed the title
alamb
left a comment
alamb
left a comment
There was a problem hiding this comment.
This looks good to me -- while it is an API change I think it is a reasonable one. Thank you @maruschin
I noticed the comments also need to be updated but we could also do that as a follow on PR as well
| a: Option<T::Native>, | ||
| d: &DataType, | ||
| ) -> Self { | ||
| ) -> Result<Self> { |
There was a problem hiding this comment.
I think the comments in this function also need to be updated (the 'panic's section is no longer correct)
/// Create a [`ScalarValue`] with the provided value and datatype
///
/// # Panics
///
/// Panics if d is not compatible with T
There was a problem hiding this comment.
with_data_type can still panic, I personally don't see anything wrong with this FWIW, panic are a perfectly valid way to handle unexpected failure imo
There was a problem hiding this comment.
Wrong with what? As in it is fine if this function panics and there is no need to propagate the error?
There was a problem hiding this comment.
Its an exceptional case that would imply some sort of schema inconsistency within the running plan, so imo panicking is perfectly valid, but then so is returning an error. The broader point is the doc is still correct
There was a problem hiding this comment.
I understand the point about the panics -- thank you
I don't have a strong opinion either way with regards to propagating errors vs panic'ing
alamb
changed the title
ScalarValue::new_primitive
alamb
changed the title
ScalarValue::new_primitiveScalarValue::new_primitive, return a Result
maruschin
force-pushed
the
remove_redundant_unwrap
branch
3 times, most recently
from
a7f55b8 to
5befee1
Compare
maruschin
force-pushed
the
remove_redundant_unwrap
branch
from
5befee1 to
40020c2
Compare
|
Thanks @maruschin |
4 participants
Which issue does this PR close?
It's a part of #3313.
Rationale for this change
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?