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

RFC: rename fail! to panic! #221

Merged
merged 1 commit into from
Sep 23, 2014
Merged

RFC: rename fail! to panic! #221

merged 1 commit into from
Sep 23, 2014

Conversation

aturon
Copy link
Member

@aturon aturon commented Aug 29, 2014

Rename "task failure" to "task panic", and fail! to panic!.

Rendered

@lilyball
Copy link
Contributor

I think this is a reasonable change, but I'm slightly concerned that "panic" implies that the entire process is failing. Perhaps Go provides sufficient precedent of a "catchable panic" to be ok with "panic" just meaning the task is dying.

That said, I can't think of an alternative that makes more sense. I agree with the motivation to move away from "failure", so "panic" is probably the best alternative. It might be nice to note this in the drawbacks section though.

@glaebhoerl
Copy link
Contributor

I am partial to despair!, as in

if num_kittens() <= 0 {
    despair!("all is lost")
}

but recognize that this is, lamentably, not serious enough to be a contender.

(I think the proposal is a good change.)

@lilyball
Copy link
Contributor

HCF!("Halt and Catch Fire")

@chris-morgan
Copy link
Member

@kballard Of course, in certain failure modes task failure may be just process abort. And even if it wasn’t supposed to be, it still might happen if a destructor fails too.

👍 in general, but I think you need to clarify further what’s going to change here. Are all relevant item names going to be changed? And in some cases where the translation is less obvious, how? To give a few specific examples of the sorts of cases we have—rust_fail (rust_panic, I presume), sync::lock::PoisonOnFail (PoisonOnPanic, I presume), core::failure (panicking sounds a little odd, even if it’s the direct translation).

@arcto
Copy link

arcto commented Aug 30, 2014

👍 I used to be a proponent of abort! but it was still ambiguous with stdlib abort().
panic! is fine.

@reem
Copy link

reem commented Aug 30, 2014

👍 regarding renaming fail! - but panic! feels a bit too loose for me, I prefer the directness of something like kill, die, or abort. panic! also doesn't translate well to discussing what is happening - fail! gives us "fail the task", panic! give us... "panic"?

We could rename abort to kill and fail to abort, if we wanted to.

@bluss
Copy link
Member

bluss commented Aug 30, 2014

Renaming our abort doesn't help -- the precedent is libc abort().

I think what is needed is a word that will tell the reader that the process named is something specific -- it won't just "fail" but it will fail the rust task and start unwinding. So a peculiar name like panic should be good. The reader won't know exactly what that is, but they will understand it's a certain process and will have to read more about panic in the rust docs.

@steveklabnik
Copy link
Member

fail! gives us "fail the task", panic! give us... "panic"?

"The task panicked."

@ben0x539
Copy link

Since this isn't supposed to be a common thing to do, could we afford to go with a more descriptive, less catchy name? Something like task_exit!, terminate_task!?

@lilyball
Copy link
Contributor

@ben0x539 That makes it sound like the goal is to terminate the task. That's not the goal, that's just what happens. The goal is to declare that something has gone wrong in an unrecoverable way and behave accordingly. Which is to say, terminate_task!() sounds like a normal mode of operation, "the task is no longer useful, let's terminate it", whereas this macro is actually meant to evoke the idea that this is an exceptional case.

@reem
Copy link

reem commented Aug 31, 2014

On further though, I've actually come to like this name because it feels like something you shouldn't do - panic! sounds like it is an uncontrolled, last-ditch operation, which fail or abort don't quite have. In truth it is not uncontrolled, but that connotation will discourage people from using it.

@bachm
Copy link

bachm commented Aug 31, 2014

crash is more descriptive in my opinion.

@glaebhoerl
Copy link
Contributor

"crash", for me, means SIGSEGV.

@pczarn
Copy link

pczarn commented Aug 31, 2014

Most of names proposed here can be associated with kernel panic, process abort or SIGSEGV. I'll mention some more names:

  • bail!()
  • ditch_task!()
  • forsake_task!()

@bluss
Copy link
Member

bluss commented Aug 31, 2014

crash_task!() in that case.

@SiegeLord
Copy link

I'm going to suggest throw!() since Rust's failures are basically exceptions anyway (unless there's a serious plan to alter the semantics of fail).

@lilyball
Copy link
Contributor

throw!() suggests that there is a catch!(), but there isn't.

@treeman
Copy link

treeman commented Sep 1, 2014

I am for a renaming. How about task_panic!()? Otherwise I'm fine with panic!().

@brendanzab
Copy link
Member

@pczarn bail!() is nice. Differentiates us from Go, and does not mix it up with kernel panics.

@tshepang
Copy link
Member

tshepang commented Sep 1, 2014

👍 for task_panic() @treeman

@Zoxc
Copy link

Zoxc commented Sep 4, 2014

abandon!("ship")

@kud1ing
Copy link

kud1ing commented Sep 11, 2014

Maybe leave!("Can't recover")

Otherwise i like panic!

@thestinger
Copy link

I think panic! is an improvement over the current naming. Naming it task_panic would imply that the failure is contained to the task, but Rust is unable to provide that guarantee. It needs to poison any mutable shared memory which forcefully propagates the failure. It will also abort if another failure occurs in a destructor. There's the possibility of recovery by a supervising task, but it's not guaranteed, and there's usually no supervision in place to handle / report the errors so they either abort or are ignored.

@FranklinChen
Copy link

I like the directness of something like die!. fail! is clearly not good enough. But panic! seems to suggest too much of a vague emotional event. Not every programmer is already familiar with existing usage as in "kernel panic".

@bkoropoff
Copy link

If you're pilfering kernel terminology, how about oops!()? It even seem roughly analagous to what fail!() currently does: it tries to limit the damage to just the current task, but depending on circumstances the entire system might go down anyway.

@arcto
Copy link

arcto commented Sep 19, 2014

Seriously, oops! is not very informative. Either pick panic! which has precedent in Go, or something novel but unequivocal such as abort_task!.

@alexcrichton
Copy link
Member

This was discussed in today's meeting and the decision was to merge.

@llogiq
Copy link
Contributor

llogiq commented Sep 24, 2014

I don't think panic! is better or worse than fail!, but if we are already bikeshedding, why not look at other options?

  • die! (kudos to perl)
  • stop!
  • cancel!
  • cut! (cue cinema)
  • snap! (imagine snapping a thread)

@richo
Copy link

richo commented Oct 9, 2014

Not trying to bikeshed or go back on this choice, but how do we make it abundantly clear to systems programmers that panic! likely doesn't do what you expect?

eg, on every other platform I've worked on that knows how to panic, there is no recovery, and nothing else happens apart maybe from dumping some state and waiting on a debugger, as opposed to here where the failure is entirely task local.

@jld
Copy link

jld commented Oct 9, 2014

Looking at the OS precedent another way: panic halts everything that was sharing memory with where the error occurred — one host in a cluster, one Rust task — while other hosts / tasks connected only by networking / message passing can detect the condition and try to continue. (This analogy isn't exact, but maybe it might help explain things.)

steveklabnik added a commit to steveklabnik/rust that referenced this pull request Oct 29, 2014
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]
SimonSapin pushed a commit to tomprogrammer/rust-ascii that referenced this pull request Nov 27, 2014
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]
steveklabnik added a commit to rust-random/rand that referenced this pull request Feb 3, 2015
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]
withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017
Add a comment explaining that we depend on SeqCst ordering.
@Centril Centril added A-panic Panics related proposals & ideas A-macros-libstd Proposals that introduce new standard library macros labels Nov 23, 2018
djrenren pushed a commit to djrenren/libtest that referenced this pull request Jan 22, 2019
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]
gnzlbg pushed a commit to rust-lang/libtest that referenced this pull request Mar 2, 2019
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]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros-libstd Proposals that introduce new standard library macros A-panic Panics related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.