Renaming task failure

[alexcrichton]

The current implementation of task failure is related to unwinding, but I think we don’t want to tie the concept of a task failure to the exact process of unwinding. I think in the past there may have been ideas of how to move away from unwinding, and it would be nice to keep those options in play (not that I know of them though!)

[aturon]

It sounds like abort is the best bet for a replacement. I’m curious whether others share my concern/frustration about the current terminology? Do we think it’s worth changing this?

[reem]

abort! to replace fail! would pair well with kill! instead of intrinsics::abort. kill! works well because it sounds like it does what it does: kill the process.

[rkjnsn]

I like die! because I am familiar with it from other languages, and it would do exactly what I would expect.

[steveklabnik]

Yeah, with the talk of maybe removing/changing unwinding, seems bad to rename it to that.

I do agree that fail has problems right now.

Go uses panic and recover: http://blog.golang.org/defer-panic-and-recover

[arcto]

How about my_bad! or epic fail!? J

+1 for abort! as it’s probably the best alternative – unless there’s even a small chance that these unwindings could be “caught” in a future Rust, in which case we’re really talking about exceptions.

[glaebhoerl]

I think if we ever add a mechanism for intra-task catchable exceptions, it should be semantically and syntactically distinct from task failure / abort / whatever (even if under the hood, they are both implemented by unwinding).

Another potential name here might be error!, which is what Haskell uses for their equivalent. But this conflicts with the current error! for logging, and might also be confusable with the Err variant of Results.

(Gah, I deleted my previous top-level comment so I could make it a reply to the particular comment I’m responding to instead, and now it’s complaining that the body is too similar…)

[arcto]

Instead of having full-fledged exception handling, I think, a lot of safe and deliberate recovery could be done if you had a kind of cheap-to-set-up task that “lends” its caller’s thread (i.e. not starting a new thread for the task).

---

Another really stupid/ingenious idea I’ve had is parameterised recovery points, akin to lifetimes for parameters.

[brson]

I am also constantly frustrated about the terminology whenever I write about error handling in Rust. My suspicion is that this pain will be amplified over time.

[ecl3ctic]

I like abort!. It tells you exactly what’s going to happen, whereas fail! simply sounds like something has gone wrong.

[liigo]

abort! Looks nice, +1!

[bachm]

Wouldn’t we be talking about task abortion if abort is chosen? I think I prefer crash.

[arcto]

I don’t particularly like “crash” because I think it carries a connotation of uncontrolled execution. I’d like to think of this kind of unwinding as safe and planned.

[reem]

abort has a nice semantic meaning - it doesn’t sound unsafe like crash or die but it does sound like something you probably shouldn’t do unless you have no other outlet.

It just makes sense in many cases - what do I do if that thing I expected to be x and it inexplicably isn’t? abort the operation.

[brson]

The only nagging worry I have about abort for this is that if the other abort ends up having a more prominent role in the spec, both being named the same will be confusing.

(I edited this post a million times. Sorry.)

[aturon]

I agree that the overlap with process-level abort is the main downside to abort!. I still think dealing with that ambiguity is easier than ambiguity around “failure” (again, since Result is becoming increasingly common), though.

@brson, what do you think about panic! or die!? (To me, I’d expect that latter to be the same as process abort, though…)

[reem]

We could just also rename process abort, that solves both problems. panic! is growing on me, though

[arcto]

panic! is somewhat vague though. It’s not clear what is happening, as opposed to abort!. Example:

foo.unwrap_or_panic(); // oh, dear!

[ecl3ctic]

I dislike all the “cute” names like panic or die. I prefer names that describe exactly what is happening without fluff or silly personifications.

[aturon]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.