Tutorial: explain how to handle task failure

[kud1ing]

The language FAQ states:

Recovery after a failure is done by trapping a task failure from outside the task,
where the typestate of other tasks is known to be unaffected.

Please add an explanation to the tutorial (section "Failure" or "Tasks"?) how this would be done.

[brson]

There's a section on task failure now in the task tutorial, but it only covers linked failure modes and task::try. Really handling task failure requires using the hideous future_result function and I haven't written anything about that yet.

[metajack]

nominating for production ready

[pnkfelix]

accepted for production ready. (Also, bug triage group agreed that this should drive effort to improve/replace the current task failure API.)

[Aatch]

Visiting for triage. The task failure API is, as far as I know, undergoing some changes, so the tasks tutorial should be updated then.

[lucab]

Is the new Conditions tutorial covering all the info needed? I think the Failure section of the tutorial describes this, but I'm unsure if Future topics should go somewhere there too...

[graydon]

The tutorial is "conditions and error handling", covers multiple strategies.

[bluss]

conditions tutorial is invisible? Pr #8764 links it in

[catamorphism]

High, 1.0

[pnkfelix]

The current conditions and error handling tutorial mentions the strategy of using supervisor tasks a couple times, but I do not think it provides a concrete example of how to code it up.

[pnkfelix]

part of #11755

[kud1ing]

http://static.rust-lang.org/doc/master/guide-tasks.html#handling-task-failure explains the issue as "While it isn't possible for a task to recover from failure, tasks may notify each other of failure".

If this is the case, this issue should be closed.

[pnkfelix]

The section @kud1ing references above does not provide a sufficient example of what is desired here. The sentence "While it isn't possible for a task to recover from failure, tasks may notify each other of failure" is followed by a concrete example using the try function, but since try blocks, it is not really helpful for someone who wants to make a real supervisor task.

@brson mentioned future_result in this ticket, but the only mention of that in the guide is a TODO.

Also, this issue says in the comments: "bug triage group agreed that this [issue] should drive effort to improve/replace the current task failure API"; I don't think that this has happened either.

So I do not think the desiderata for this ticket have been satisfied (though I do appreciate @kud1ing taking the time to close it since they were the original filer of the ticket).

Reopening.

[brson]

Nominating for removal from milestone.

[pnkfelix]

#3725 is related.

Removing from milestone, as the doc issue that this is dedicated to can be handled independently (and post 1.0) from #3725

[pnkfelix]

(not 1.0, P-low)

[steveklabnik]

The tutorial is not going to improve, and when I re-write the Task guide, it will contain information about how things should fail. Should this just be closed?

[pnkfelix]

@steveklabnik if you want to attach this ticket to some metabug for your guide (while still leaving this ticket open), that is fine with me.

I am opposed to simply closing this ticket, since I interpret closing a ticket as implying that the need described in the issue has been satisfied (or is not something we intend to try to satisfy) -- closing by saying "this issue will be satisfied by this other task over here" is not legitimate IMO.

[steveklabnik]

Sounds good to me, I don't mind either way. I'll consider this ticket as applying to that guide rather than to the tutorial.