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

Soft-deprecate the description() method of the Error trait #49536

Closed
wants to merge 4 commits into from
Closed
Changes from all commits
Commits
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
63 changes: 24 additions & 39 deletions src/libstd/error.rs
Original file line number Diff line number Diff line change
Expand Up @@ -9,34 +9,6 @@
// except according to those terms.

//! Traits for working with Errors.
//!
//! # The `Error` trait
//!
//! `Error` is a trait representing the basic expectations for error values,
//! i.e. values of type `E` in [`Result<T, E>`]. At a minimum, errors must provide
//! a description, but they may optionally provide additional detail (via
//! [`Display`]) and cause chain information:
//!
//! ```
//! use std::fmt::Display;
//!
//! trait Error: Display {
//! fn description(&self) -> &str;
//!
//! fn cause(&self) -> Option<&Error> { None }
//! }
//! ```
//!
//! The [`cause`] method is generally used when errors cross "abstraction
//! boundaries", i.e. when a one module must report an error that is "caused"
//! by an error from a lower-level module. This setup makes it possible for the
//! high-level module to provide its own errors that do not commit to any
//! particular implementation, but also reveal some of its implementation for
//! debugging via [`cause`] chains.
//!
//! [`Result<T, E>`]: ../result/enum.Result.html
//! [`Display`]: ../fmt/trait.Display.html
//! [`cause`]: trait.Error.html#method.cause

#![stable(feature = "rust1", since = "1.0.0")]

Expand All @@ -63,33 +35,46 @@ use num;
use str;
use string;

/// Base functionality for all errors in Rust.
/// `Error` is a trait representing the basic expectations for error values,
/// i.e. values of type `E` in [`Result<T, E>`]. Errors must describe
/// themselves through the [`Display`] and [`Debug`] traits, and may provide
/// cause chain information:
///
/// The [`cause`] method is generally used when errors cross "abstraction
/// boundaries", i.e. when a one module must report an error that is "caused"
/// by an error from a lower-level module. This setup makes it possible for the
/// high-level module to provide its own errors that do not commit to any
/// particular implementation, but also reveal some of its implementation for
/// debugging via [`cause`] chains.
///
/// [`Result<T, E>`]: ../result/enum.Result.html
/// [`Display`]: ../fmt/trait.Display.html
/// [`cause`]: trait.Error.html#method.cause
#[stable(feature = "rust1", since = "1.0.0")]
pub trait Error: Debug + Display {
/// A short description of the error.
/// **This method is soft-deprecated.**
///
/// The description should only be used for a simple message.
/// It should not contain newlines or sentence-ending punctuation,
/// to facilitate embedding in larger user-facing strings.
/// For showing formatted error messages with more information see
/// [`Display`].
/// Although using it won’t cause compilation warning,
/// new code should use [`Display`] instead
/// and new `impl`s can omit it.
///
/// [`Display`]: ../fmt/trait.Display.html
///
/// # Examples
///
/// ```
/// use std::error::Error;
///
/// match "xc".parse::<u32>() {
/// Err(e) => {
/// println!("Error: {}", e.description());
/// // Print `e` itself, not `e.description()`.
/// println!("Error: {}", e);
/// }
/// _ => println!("No error"),
/// }
/// ```
#[stable(feature = "rust1", since = "1.0.0")]
fn description(&self) -> &str;
fn description(&self) -> &str {
""
Copy link
Member

Choose a reason for hiding this comment

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

Hm, could we at least make this something like "default error description" or "error"? I worry that existing code that calls this would be confusing to read output logs when description isn't implemented since println!("{}", e.description()); results in an empty line being printed -- giving no indication as to the source, making such a problem hard to debug.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe something along lines of "use Display to get the description"?

}

/// The lower-level cause of this error, if any.
///
Expand Down