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.

Sign up for GitHub

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 guidelines for choosing panics or error results #6958

Merged
merged 5 commits into from
Jan 13, 2025
Merged

add guidelines for choosing panics or error results #6958

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7b7f51b
add guidelines for choosing panics or error results
Jan 9, 2025
d423b01
add note to clarify that checking invalidity of user input is the key…
Jan 9, 2025
907a43d
apply reviewer suggestions
jp0317 Jan 10, 2025
974c4e5
remove redundant word
jp0317 Jan 10, 2025
12a9bea
fix markdown format
jp0317 Jan 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,16 @@ Planned Release Schedule
| Dec 2024 | `0.11.2` | Minor, NO breaking API changes |
| Feb 2025 | `0.12.0` | Major, potentially breaking API changes |

### Guidelines for `panic` vs `Result`

In general, use panics for bad states that are unreachable, unrecoverable or harmful.
For those caused by invalid user input, however, we prefer to report that invalidity
gracefully as an error result instead of panicking. In general, invalid input should result
in an `Error` as soon as possible. It _is_ ok for code paths after validation to assume
validation has already occurred and panic if not. See [this ticket] for more nuances.

[this ticket]: https://github.com/apache/arrow-rs/issues/6737

### Deprecation Guidelines

Minor releases may deprecate, but not remove APIs. Deprecating APIs allows
Expand Down
Loading