[DISCUSS] Remove panics
- Dominant language
- Rust
- Stars
- 3.6k
- Forks
- 1.3k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 169
Description
**Is your feature request related to a problem or challenge? Please describe what you are trying to do.**
I would like to remove (or at least provide a non-panicking) interface for arrow-rs to have. I spoke with @alamb while at Databricks Data and AI Conference and he mentioned making an issue before I got deep into the weeds implementing something.
**Describe the solution you'd like**
There are a couple ways to go about this.
1. Remove the panics. This would be multiple API breaking changes across the board, so this is not nice from a compatibility standpoint. Ideally, I don't think this is the right way to go here.
2. Add `try_*` methods instead. For example:
```rust
pub fn as_generic_list_array(arr: &dyn Array) -> &GenericListArray {
arr.as_any()
.downcast_ref::>()
.expect("Unable to downcast to list array")
}
```
Becomes
```rust
pub fn try_as_generic_list_array(arr: &dyn Array) -> Option<&GenericListArray> {
arr.as_any().downcast_ref::>()
}
pub fn as_generic_list_array(arr: &dyn Array) -> &GenericListArray {
try_as_generic_list_array(arr).expect("Unable to downcast to list array")
}
```
This mechanism is employed in multiple places already, if this approach is preferred this would unify that approach to be consistent across all of the code base.
I'm basically looking for a preference to get started upon. I can introduce new Error types as necessary for result types, but I think #2 for options is a good place to start.
Contributor guide
Research direction
Start by surveying the existing panicking array-cast interfaces and the places where try_* methods already exist, as described in the issue. First establish whether the project prefers non-panicking Option-returning methods or a different error-based API; done means an agreed, consistent scope rather than an isolated implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100