diff options
| author | Steve Klabnik <steve@steveklabnik.com> | 2014-10-09 15:17:22 -0400 |
|---|---|---|
| committer | Steve Klabnik <steve@steveklabnik.com> | 2014-10-29 11:43:07 -0400 |
| commit | 7828c3dd2858d8f3a0448484d8093e22719dbda0 (patch) | |
| tree | 2d2b106b02526219463d877d480782027ffe1f3f /src/libarena | |
| parent | 3bc545373df4c81ba223a8bece14cbc27eb85a4d (diff) | |
Rename fail! to panic!
https://github.com/rust-lang/rfcs/pull/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]
Diffstat (limited to 'src/libarena')
| -rw-r--r-- | src/libarena/lib.rs | 9 |
1 files changed, 4 insertions, 5 deletions
diff --git a/src/libarena/lib.rs b/src/libarena/lib.rs index 1cd6f7f6685..924dd5ffed6 100644 --- a/src/libarena/lib.rs +++ b/src/libarena/lib.rs @@ -69,7 +69,7 @@ impl Chunk { /// element). When the arena is destroyed, it iterates through all of its /// chunks, and uses the tydesc information to trace through the objects, /// calling the destructors on them. One subtle point that needs to be -/// addressed is how to handle failures while running the user provided +/// addressed is how to handle panics while running the user provided /// initializer function. It is important to not run the destructor on /// uninitialized objects, but how to detect them is somewhat subtle. Since /// `alloc()` can be invoked recursively, it is not sufficient to simply exclude @@ -162,7 +162,7 @@ unsafe fn destroy_chunk(chunk: &Chunk) { // We encode whether the object a tydesc describes has been // initialized in the arena in the low bit of the tydesc pointer. This -// is necessary in order to properly do cleanup if a failure occurs +// is necessary in order to properly do cleanup if a panic occurs // during an initializer. #[inline] fn bitpack_tydesc_ptr(p: *const TyDesc, is_done: bool) -> uint { @@ -337,10 +337,9 @@ fn test_arena_destructors_fail() { // things interesting. arena.alloc(|| { [0u8, 1u8, 2u8] }); } - // Now, fail while allocating + // Now, panic while allocating arena.alloc::<Rc<int>>(|| { - // Now fail. - fail!(); + panic!(); }); } |
