lance-format / lance-format/lance

Improve error type

Open
#4,603 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Rust
Stars
7.1k
Forks
852
Avg merge
3d 18h
Merged PRs (30d)
272

Description

The current error types suffer from a few problems:

  1. It's hard to differentiate between user input issues and internal issues (for example, with schema errors.)
  2. For internal errors, we often wish we had a backtrace.

Design

For classifying errors, I propose a three tier system:

  1. Status code: the general type of error. This could be inspired by HTTP errors. For example, 400 for BadRequest.
  2. Title: a short static description of the error. For example, "Table not found".
  3. Description: a dynamic string containing details specific to the instance. For example: "Table 'foo' not found in database 'bar'."

In addition, should include:

  • The version of Lance (to make this easy to see from error reports)
  • An optional Backtrace or Location. We should design the constructor for internal errors to always prefer a Backtrace when available.
// To keep the size of Result<T> small, we use a Box<InnerError> to store the
// actual error. This way, the size of Result<T> is just a pointer.
pub struct Error(pub Box<InnerError>);

/// Lance's generic error.
///
/// The error aims to make it easy to determine error handling. Errors can be
/// classified at three levels:
///
/// * status_code: generic kind of error. We re-use HTTP status codes since
///   they are well known.
/// * title: a specific kind of error. For example, "Table not found."
/// * details: the details for an instance of the error.
pub struct InnerError {
    /// An HTTP status code that best describes the error.
    pub status_code: StatusCode,
    /// A short description of the error. For example, "Table not found.".
    ///
    /// This should not contain details of the instance of the error. Instead,
    /// save that for `details`. This should be the same for all instances of
    /// the same error, and thus is a static string.
    pub title: &'static str,
    /// A longer description of the error, including details specific to the
    /// instance. For example, "Table 'foo' not found in database 'bar'.".
    pub details: String,
    /// The underlying cause of the error, if any.
    pub cause: Option<BoxedError>,
    /// The backtrace or location of the error.
    pub backtrace: MaybeBacktrace,
    /// Version of the Lance library
    pub version: &'static LanceVersion
}

pub enum MaybeBacktrace {
    Captured(Backtrace),
    Location(&'static std::panic::Location<'static>),
    None,
}

Development

  • Define new error type
  • Provide conversion from existing error type to new error type
  • Iteratively go through libraries replacing creation of old error type with new error type

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the existing error type and its conversions across the Lance libraries; the issue names no files or tests. Compare them with the proposed Error, InnerError, and MaybeBacktrace design, then define the new type, add conversions, and replace old error creation throughout the libraries.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.