Allow the task failure message to be caught

[brson]

I've occasionally wanted this (for example, it would enable better error reporting for ICEs) but haven't gotten around to implementing it. It should be quite easy now though. In core::rt::fail stash the value in TLS, then in the task cleanup code, pull it out of TLS and put it into the notification message. Modify task::try to return the string.

Ideally this will someday be an ~any type instead of ~str.

[brson]

Oh, there is one failure path that doesn't go through core::rt::rt_fail - the out of stack failure. We'll have to account for that. Someday we'll need to also handle the out of stack failure from Rust code as well.

[bblum]

are there plans for bringing back the any type? exception handling is the only place i can think of where it would be useful.

the way sml does this is by having a global disjunctive exception ("extensible") type for which exception Name(args) at the top level will add a new arm, and anywhere you match on it you have to have a fallthrough case. not sure if this is what we'd want to do, but at least there's precedent.

[brson]

There hasn't been any talk about any recently and we haven't had a pressing need for it. At this point I think it will likely just be implemented in the library.

I'd also like to use any for an imaginary RustScript language.

[bblum]

It would also be really nice if fail didn't have to allocate, especially if throwing an extensible exception type. Instead of shoving it through C++'s one-word-sized stack unwinding data, the fail wrapper function in libcore should probably just put it in TLS.

[bblum]

For lack of an any type, the best thing I can think of is a utility function that just uses a supervised task and a oneshot pipe internally: fn handle<T: send>(blk: fn(throw: fn(T) -> !)) -> Option<T>. Use it sort of like:

assert do handle |throw| {
    throw(some_val);
}.is_some();

Of course the built-in version would be better (more convenient, no memory allocation) and would only require T: owned instead of T: send.

(edit: if i am not mistaken, this is basically callcc.)

[bblum]

It occurs to me with an any type we could also support unboxing traits. (assuming the way to deal with any would be a type-level match.)

[pnkfelix]

From the comments it seems like this issue has had an unfortunate bifurcation. There are two issues of interest:

1. Adding the ability for task::try to catch and manipulate the value passed to fail!.
2. Add an any type, which could be useful for exception handling code patterns, such as (1.).

The value passed to fail! is currently constrained to being a ~str, but that is (or at least should be) orthogonal to the description provided in (1).

I would prefer that the two topics be kept separate, especially since the meta-data on this issue (like "E-Easy") probably only applies if it is focused on (1) alone, and not (2) as well.

[pnkfelix]

(Let's try to move future discussion of a potential any type to #61 perhaps?)

[brson]

Related to #6874

[catamorphism]

I'm attempting to do this, as it would make rustpkg testing a lot easier.

[Kimundi]

@catamorphism I'm also looking into enabling this, but I'm still struggling with understanding how to pass the message along in the unwinding system.

I have a working implementation of a Any trait here: https://gist.github.com/Kimundi/6802198, and I'm trying a system where a failure cause is a enum of either a std::send_str::SendStr or a ~Any.

One thing I'm not sure how to handle is linked task failure, as that would mean sending a Sendable thing to multiple receivers at once. Maybe just have them receive a enum variant LinkedFailure or so.

Also, I still need to figure out how to adapt the Any trait to allow things like to_str() for the containing type without copying all code I have written for it.

Anyway, just wanted to pass my notes along.

[catamorphism]

@Kimundi Ah ok. I'm not trying to be that ambitious -- just trying to make the ~str part of it work. A more general solution would be better, of course!