[rust-dev] Lightweight failure handling

Phil Dawes phil at phildawes.net
Thu Mar 27 10:51:31 PDT 2014


Hello!

@Clark: I must've hit reply instead of reply-all, thanks for re-adding
rust-dev.
I'm not sure I agree about the fail! thing. I think crashing a task on an
unexpected condition is easier to code and to reason about. It forces me to
think about recovery and atomicity. Also even if I structured my code to
return option<> from every call site I'd still have the possibility of e.g.
array out-of-bounds failures.

@Matthieu: Awesome thanks. When I get some time I need to dig into task
internals and try to implement this.

Thanks,

Phil



On Thu, Mar 27, 2014 at 5:19 PM, Matthieu Monrocq <
matthieu.monrocq at gmail.com> wrote:

>
>
>
> On Thu, Mar 27, 2014 at 3:43 PM, Clark Gaebel <cg.wowus.cg at gmail.com>wrote:
>
>> aside: Your last message didn't get CC'd to rust-dev. I've re-added them,
>> and hope dearly I haven't committed a social faux pas.
>>
>> That's interesting. You're kinda looking for exception handling in rust!
>> Unfortunately the language seems pretty principled in its opinion that
>> failure should be handled at the task boundary exclusively, and this is a
>> pretty heavyweight opinion.
>>
>> This wouldn't be so bad if people would stop fail!ing everywhere! I'm
>> personally very against the seemingly growing trend of people doing things
>> like calling unwrap() on options instead of propagating errors up. This
>> makes accidental failure far, far more common than it should be.
>>
>> I hope when higher-kinded-types and unboxed closures land, people will
>> start using a monadic interface to results and options, as this will
>> hopefully make error propagation less painful. We'll see.
>>
>> As for your specific case, I don't really have an answer. Is "just don't
>> call fail!" an option? Maybe an automatically-inferred #[will_not_fail]
>> annotation has a place in the world...
>>
>>   - Clark
>>
>>
> Actually, there is nothing in the task model that prevents them from being
> run "immediately" in the same OS thread, and on the same stack. It just is
> an implementation detail.
>
> In the behavior, the main difference between try/catch in Java and a Task
> in Rust is that a Task does not leave a half-corrupted environment when it
> exits (because everything it interacted with dies with it).
>
> Implementation-wise, there may be some hurdles to get a "contiguous" task
> as cheap as a try/catch: unwind boundary, detecting that the task is viable
> for that optimization at the spawn point, etc... but I can think of nothing
> that is absolutely incompatible. I would be happy for a more knowledgeable
> person to chime in on this point.
>
> -- Matthieu
>
>
>
>>
>> On Thu, Mar 27, 2014 at 3:51 AM, Phil Dawes <rustphil at phildawes.net>wrote:
>>
>>> Hi Clark,
>>>
>>> Thanks for the clarification.
>>> To follow your example, there are multiple 'process_msg()' steps, and if
>>> one fails I don't want it to take down the whole loop.
>>>
>>> Cheers,
>>>
>>> Phil
>>>
>>>
>>>
>>> On Wed, Mar 26, 2014 at 10:25 PM, Clark Gaebel <cg.wowus.cg at gmail.com>wrote:
>>>
>>>> Sorry, was on my phone. Hopefully some sample code will better
>>>> illustrate what I'm thinking:
>>>>
>>>> loop {
>>>>   let result : Result<Foo, ()> = task::try(proc() {
>>>>     loop {
>>>>       recv_msg(); // begin latency sensitive part
>>>>       process_msg();
>>>>       send_msg (); // end latency sensitive part
>>>>     }
>>>>   });
>>>>
>>>>   if result.is_ok() {
>>>>     return result;
>>>>   } else {
>>>>     continue;
>>>>   }
>>>> }
>>>>
>>>> This way, you only pay for the try if you have a failure (which should
>>>> hopefully be infrequently), and you get nice task isolation!
>>>>
>>>>
>>>> On Wed, Mar 26, 2014 at 6:05 PM, Clark Gaebel <cg.wowus.cg at gmail.com>wrote:
>>>>
>>>>> The "main loop" of your latency sensitive application.
>>>>> On Mar 26, 2014 5:56 PM, "Phil Dawes" <rustphil at phildawes.net> wrote:
>>>>>
>>>>>> On Wed, Mar 26, 2014 at 9:44 PM, Clark Gaebel <cg.wowus.cg at gmail.com>wrote:
>>>>>>
>>>>>>> Can't you put that outside your inner loop?
>>>>>>>
>>>>>>
>>>>>> Sorry Clark, you've lost me. Which inner loop?
>>>>>>
>>>>>> _______________________________________________
>>>>>> Rust-dev mailing list
>>>>>> Rust-dev at mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Clark.
>>>>
>>>> Key ID     : 0x78099922
>>>> Fingerprint: B292 493C 51AE F3AB D016  DD04 E5E3 C36F 5534 F907
>>>>
>>>
>>>
>>
>>
>> --
>> Clark.
>>
>> Key ID     : 0x78099922
>> Fingerprint: B292 493C 51AE F3AB D016  DD04 E5E3 C36F 5534 F907
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140327/01fb2ed5/attachment.html>


More information about the Rust-dev mailing list