Move description of the Error trait to its own doc-comment

… rather than the module’s.

Remove code definition of the Error trait from its doc-comment

It was out of date, and rustdoc already shows the same information.

Add a default impl for Error::description and document it as deprecated.

It is redundant with Display while being much less flexible for implementors.

This is only a "soft" deprecation: it is not worth the hassle of a warning to existing users.

Tweak Error trait docs to reflect actual requirements
This commit is contained in:
Simon Sapin
2018-03-31 12:09:10 +02:00
committed by Kornel
parent 25749ad66d
commit a5655b81a3

View File

@@ -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")]
@@ -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 wont 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 {
""
}
/// The lower-level cause of this error, if any.
///