Skip to content

Commit

Permalink
Rename fail! to panic!
Browse files Browse the repository at this point in the history
rust-lang/rfcs#221

The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.

Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.

We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.

To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:

    grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'

You can of course also do this by hand.

[breaking-change]
  • Loading branch information
steveklabnik committed Oct 29, 2014
1 parent 21e0fa0 commit ae1c418
Show file tree
Hide file tree
Showing 2 changed files with 5 additions and 5 deletions.
2 changes: 1 addition & 1 deletion distributions/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -129,7 +129,7 @@ impl<'a, T: Clone> WeightedChoice<'a, T> {
for item in items.iter_mut() {
running_total = match running_total.checked_add(&item.weight) {
Some(n) => n,
None => fail!("WeightedChoice::new called with a total weight \
None => panic!("WeightedChoice::new called with a total weight \
larger than a uint can contain")
};

Expand Down
8 changes: 4 additions & 4 deletions lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -92,7 +92,7 @@ pub trait Rng {
/// not be relied upon.
///
/// This method should guarantee that `dest` is entirely filled
/// with new data, and may fail if this is impossible
/// with new data, and may panic if this is impossible
/// (e.g. reading past the end of a file that is being used as the
/// source of randomness).
///
Expand Down Expand Up @@ -375,7 +375,7 @@ impl Rng for XorShiftRng {
}

impl SeedableRng<[u32, .. 4]> for XorShiftRng {
/// Reseed an XorShiftRng. This will fail if `seed` is entirely 0.
/// Reseed an XorShiftRng. This will panic if `seed` is entirely 0.
fn reseed(&mut self, seed: [u32, .. 4]) {
assert!(!seed.iter().all(|&x| x == 0),
"XorShiftRng.reseed called with an all zero seed.");
Expand All @@ -386,7 +386,7 @@ impl SeedableRng<[u32, .. 4]> for XorShiftRng {
self.w = seed[3];
}

/// Create a new XorShiftRng. This will fail if `seed` is entirely 0.
/// Create a new XorShiftRng. This will panic if `seed` is entirely 0.
fn from_seed(seed: [u32, .. 4]) -> XorShiftRng {
assert!(!seed.iter().all(|&x| x == 0),
"XorShiftRng::from_seed called with an all zero seed.");
Expand Down Expand Up @@ -446,7 +446,7 @@ pub struct Closed01<F>(pub F);

#[cfg(not(test))]
mod std {
pub use core::{option, fmt}; // fail!()
pub use core::{option, fmt}; // panic!()
}

#[cfg(test)]
Expand Down

0 comments on commit ae1c418

Please sign in to comment.