Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add arrow_err! macros, optional backtrace to ArrowError #8586

Merged
merged 3 commits into from
Dec 21, 2023

Conversation

comphead
Copy link
Contributor

@comphead comphead commented Dec 19, 2023

Which issue does this PR close?

Closes partially #7360.

Rationale for this change

Continue covering Datafusion Errors with error macros supporting optional backtrace

What changes are included in this PR?

introduced arrow_err! and arrow_datadusion_err! macros with optional backtrace, to represent Err(DatafusionError::ArrowError) and DatafusionError::ArrowError(_)

Are these changes tested?

Yes

Are there any user-facing changes?

No

@github-actions github-actions bot added physical-expr Physical Expressions optimizer Optimizer rules core Core DataFusion crate sqllogictest SQL Logic Tests (.slt) labels Dec 19, 2023
@comphead comphead mentioned this pull request Dec 19, 2023
23 tasks
@comphead comphead changed the title Introducing arrow_err! macros Add arrow_err! macros Dec 19, 2023
@alamb alamb changed the title Add arrow_err! macros Add arrow_err! macros, optional backtrace to ArrowError Dec 20, 2023
Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

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

Thank you for the contribution @comphead

Looks like a good improvement in error handing to me

@@ -802,7 +802,7 @@ impl<'a, S: SimplifyInfo> TreeNodeRewriter for Simplifier<'a, S> {
&& !info.get_data_type(&left)?.is_floating()
&& is_zero(&right) =>
{
return Err(DataFusionError::ArrowError(ArrowError::DivideByZero));
return plan_err!("Divide by zero");
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the idea that since the error wasn't actually generated by Arrow then we shouldn't return an Arrow error?

In theory having a structured ArrowError would be more specific than a general PlanError with a "Divide by zero" message, but I am not sure how much it matters 🤷

Copy link
Contributor Author

@comphead comphead Dec 21, 2023

Choose a reason for hiding this comment

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

Thanks @alamb for this specific case I have doubled checked before modification but there is no arrow kernel being called directly like in other scenarios when ArrowError is thrown, that was the reason to change

@comphead comphead merged commit df806bd into apache:main Dec 21, 2023
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Core DataFusion crate optimizer Optimizer rules physical-expr Physical Expressions sqllogictest SQL Logic Tests (.slt)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants