RFC: rename fail! to panic! #221
Conversation
|
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. |
|
I am partial to but recognize that this is, lamentably, not serious enough to be a contender. (I think the proposal is a good change.) |
|
|
|
@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— |
|
👍 I used to be a proponent of |
|
👍 regarding renaming We could rename |
|
Renaming our abort doesn't help -- the precedent is libc 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. |
"The task panicked." |
|
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 |
|
@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, |
|
On further though, I've actually come to like this name because it feels like something you shouldn't do - |
|
|
|
"crash", for me, means SIGSEGV. |
|
Most of names proposed here can be associated with kernel panic, process abort or SIGSEGV. I'll mention some more names:
|
|
|
|
I'm going to suggest |
|
|
|
I am for a renaming. How about |
|
@pczarn |
|
👍 for |
|
|
|
Maybe Otherwise i like |
|
I think |
alexcrichton
force-pushed
the
master
branch
from
6357402
to
e0acdf4
Compare
|
I like the directness of something like |
|
If you're pilfering kernel terminology, how about |
|
Seriously, |
|
This was discussed in today's meeting and the decision was to merge. |
|
I don't think
|
|
Not trying to bikeshed or go back on this choice, but how do we make it abundantly clear to systems programmers that 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. |
|
Looking at the OS precedent another way: |
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]
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]
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]
Add a comment explaining that we depend on SeqCst ordering.
Centril
added
A-panic
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]
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]
Rename "task failure" to "task panic", and
fail!topanic!.Rendered