Skip to content

Conversation

@2010YOUY01
Copy link
Contributor

Which issue does this PR close?

Rationale for this change

#18613 is almost finished, I searched the codebase and refactor all the remaining patterns in this PR.

Such assertion macros have been scattered to the codebase, and I have also added some error handling doc in #18762, so later we can follow this pattern and continue adopting those macros.

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

@github-actions github-actions bot added optimizer Optimizer rules core Core DataFusion crate catalog Related to the catalog crate common Related to common crate proto Related to proto crate datasource Changes to the datasource crate spark labels Nov 17, 2025
Comment on lines 1717 to 1724
let validation = validate_decimal_precision_and_scale::<Decimal32Type>(
*precision, *scale,
) {
return _internal_err!("Invalid precision and scale {err}");
}
if *scale < 0 {
return _internal_err!("Negative scale is not supported");
}
);
assert_or_internal_err!(
validation.is_ok(),
"Invalid precision and scale {}",
validation.unwrap_err()
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems more appropriate to do a map_err here? (Same for below)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Updated in 09c15ee

Comment on lines 779 to 782
assert_or_internal_err!(
union.inputs.len() >= 2,
"Protobuf deserialization error, Union was require at least two input."
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should technically be an exec error I guess?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It depends I think. For SQL/Dataframe APIs, this should be an internal error, however for low level rust APIs, technically you can construct such plan and make it an execution error. So I slightly prefer to leave it as is.

assert_eq_or_internal_err!(
(iv.months, iv.days, iv.nanoseconds),
(0, 0, 0),
"row {i}: expected (0,0,0), got ({},{},{})",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: assert_eq_or_internal_err() already prints the left and right values (

"Assertion failed: {} == {} (left: {:?}, right: {:?}): {}",
), so this will duplicate this information.

assert_eq_or_internal_err!(
(iv.months, iv.days, iv.nanoseconds),
(0, 0, 0),
"expected scalar 0s, got ({},{},{})",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

2010YOUY01 and others added 2 commits November 18, 2025 15:39
Co-authored-by: Martin Grigorov <martin-g@users.noreply.github.com>
Co-authored-by: Martin Grigorov <martin-g@users.noreply.github.com>
@2010YOUY01 2010YOUY01 added this pull request to the merge queue Nov 18, 2025
Merged via the queue into apache:main with commit 19865b3 Nov 18, 2025
32 checks passed
logan-keede pushed a commit to logan-keede/datafusion that referenced this pull request Nov 23, 2025
## Which issue does this PR close?

<!--
We generally require a GitHub issue to be filed for all bug fixes and
enhancements and this helps us generate change logs for our releases.
You can link an issue to this PR using the GitHub syntax. For example
`Closes apache#123` indicates that this PR will close issue apache#123.
-->

- Closes apache#18613

## 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.
-->
apache#18613 is almost finished, I searched the codebase and refactor all the
remaining patterns in this PR.

Such assertion macros have been scattered to the codebase, and I have
also added some error handling doc in
apache#18762, so later we can follow
this pattern and continue adopting those macros.

## 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?

<!--
We typically require tests for all PRs in order to:
1. Prevent the code from being accidentally broken by subsequent changes
2. Serve as another way to document the expected behavior of the code

If tests are not included in your PR, please explain why (for example,
are they covered by existing tests)?
-->

## 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 add the `api
change` label.
-->

---------

Co-authored-by: Martin Grigorov <martin-g@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

catalog Related to the catalog crate common Related to common crate core Core DataFusion crate datasource Changes to the datasource crate optimizer Optimizer rules proto Related to proto crate spark

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Tracking] Refactor with assert_or_internal_err!() across the codebase

3 participants