apache / apache/arrow-rs

[DISCUSS] Remove panics

Open
#7,806 10 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.