Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Error Handling in Rust

lucumr.pocoo.org

Post reply on HN
Print view View original

41–50 of 82 posts

Re: On Error Handling in Rust

#41

Post by kibwen »

benjaminjackman wrote: post #32

I am not that familiar with Rust, however every time I see it I am more and more impressed. One thing that I don't see here but which I think it might be important is to grab the stack trace in the failure, or atleast the Filename / Line Number of where each Err is allocated. It will be really useful to be able to see the details for figuring out what went wrong, and following the stack trace is very important. With…

  > not sure if Rust has return type inference of not
Rust has return type inference for function invocations, but not for function signatures. This is a conscious decision to force all functions to provide an explicit contract rather than having any global type inference. And really, I wouldn't want function return types to be completely inferred in Rust given its last-semicolon rule.

However, there is an RFC that would allow for "abstract return types", which would let a function state that its return type implements a certain trait and allow the programmer to omit the concrete type. This is somewhat essential for the new closure design, and also greatly benefits functions that return iterators (but it might not be relevant to your question at all, I haven't had my tea yet...).

https://github.com/rust-lang/rfcs/pull/105/files

  > when is Rust going to compile to Javascript
Never officially, but that doesn't mean an Emscripten backend isn't possible https://github.com/rust-lang/rust/issues/2235 :)

Re: On Error Handling in Rust

#42

Post by steveklabnik »

kibwen wrote: post #35
lmm wrote: post #31

In some ways it's heartening to see Rust working everything out for itself - but it's also painful to watch the language stumble on the same problems that we've already solved. You're going to hit the same problem again with async, with transactions, and with resource management; indeed some of the stuff I've already seen about borrowing and the like seems achingly close to the same pattern. Introducing new sigils li…

HKT is indeed on the long-term roadmap, but it remains to be seen whether a design can be devised that plays nicely with the fundamental features of Rust (note that the language reserves the unused `do` keyword for just this purpose). Doing this properly is very much research-project territory. And unless I'm reading the RFC incorrectly, I think this is more principled than you're making it out to be. `FromError` is…

> (note that the language reserves the unused `do` keyword for just this purpose).

I'm not entirely sure it's just for this purpose. `do` used to mean something in Rust, but when that syntax was removed, the keyword just wasn't freed up. Of course, if we do gain HKT, it will be nice to have it, but I'm not sure that was the justification at the time.

Re: On Error Handling in Rust

#43

Post by steveklabnik »

zubspace wrote: post #25

I' m someone who hasn't tried rust, yet. Is FromError the same like inner exceptions in C#? I'd like to dive into rust once, but somehow I do not see the elegance in the code shown. I mostly do not care about the type of error condition and handle the error somewhere really far up the stack (log or messagebox) and provide the ability for a retry. Can i do something like a general try/catch far up the stack? in my opi…

> Can i do something like a general try/catch far up the stack?

Rust does not have exceptions, so not exactly. You _could_ spin up a new task (thread) with the code, and then monitor that task for failure.

Re: On Error Handling in Rust

#44

Post by steveklabnik »

masklinn wrote: post #19
echaozh wrote: post #5

So it's a specialized mapping operator for the Result functor. Why restrict it to Result only? What about using option to denote a failure condition without a specific reason? Or other kinds of interesting functors?

> What about using option to denote a failure condition without a specific reason? Result is set up and marked to mandate its use, the compiler will complain if you ignore the result of a function returning a Result, not so for an Option. So idiomatically denoting a failure condition without a specific reason is Result not Option : http://doc.rust-lang.org/std/result/#result-and-option . Option is for what it's name…

> Result is set up and marked to mandate its use,

To elaborate on this slightly, it's not that Result is special cased by the compiler, there's a 'must_use' attribute which ensures that you get a warning if you ignore it, and the definition of Result has it.

Re: On Error Handling in Rust

#45

Post by steveklabnik »

benjaminjackman wrote: post #32

I am not that familiar with Rust, however every time I see it I am more and more impressed. One thing that I don't see here but which I think it might be important is to grab the stack trace in the failure, or atleast the Filename / Line Number of where each Err is allocated. It will be really useful to be able to see the details for figuring out what went wrong, and following the stack trace is very important. With…

Rust used to also have Either, and it was changed to Result for the same reasons. Name things what they mean. :)

Re: On Error Handling in Rust

#46

Post by kibwen »

steveklabnik wrote: post #42
kibwen wrote: post #35

Earlier quoted context omitted.

HKT is indeed on the long-term roadmap, but it remains to be seen whether a design can be devised that plays nicely with the fundamental features of Rust (note that the language reserves the unused `do` keyword for just this purpose). Doing this properly is very much research-project territory. And unless I'm reading the RFC incorrectly, I think this is more principled than you're making it out to be. `FromError` is…

> (note that the language reserves the unused `do` keyword for just this purpose). I'm not entirely sure it's just for this purpose. `do` used to mean something in Rust, but when that syntax was removed, the keyword just wasn't freed up. Of course, if we do gain HKT, it will be nice to have it, but I'm not sure that was the justification at the time.

Removing the old notation was certainly not solely motivated by wanting to free up the keyword, but the reason that it remains reserved is in anticipation of future use, rather than simple negligence (though of course this decision could be reversed before 1.0).

Re: On Error Handling in Rust

#47

Post by steveklabnik »

kibwen wrote: post #46
steveklabnik wrote: post #42

Earlier quoted context omitted.

> (note that the language reserves the unused `do` keyword for just this purpose). I'm not entirely sure it's just for this purpose. `do` used to mean something in Rust, but when that syntax was removed, the keyword just wasn't freed up. Of course, if we do gain HKT, it will be nice to have it, but I'm not sure that was the justification at the time.

Removing the old notation was certainly not solely motivated by wanting to free up the keyword, but the reason that it remains reserved is in anticipation of future use, rather than simple negligence (though of course this decision could be reversed before 1.0).

Right, I guess I meant that it's not just for HKT, but for something useful.

Anyway, none of this particularly matters.

Re: On Error Handling in Rust

#48

Post by kibwen »

steveklabnik wrote: post #45
benjaminjackman wrote: post #32

I am not that familiar with Rust, however every time I see it I am more and more impressed. One thing that I don't see here but which I think it might be important is to grab the stack trace in the failure, or atleast the Filename / Line Number of where each Err is allocated. It will be really useful to be able to see the details for figuring out what went wrong, and following the stack trace is very important. With…

Rust used to also have Either, and it was changed to Result for the same reasons. Name things what they mean. :)

Funnily enough, we actually used to have both Either and Result, until one day we went through and realized that no code in existence was using Either and decided to go all-in on Result instead.

Re: On Error Handling in Rust

#49

Post by kibwen »

jeremyjh wrote: post #10

I hope we get some sugar here, the ? operator is a great idea. I like the trait implementation as well. I think Rust needs multiple dispatch though - a given type needs to support conversions of IOError to different custom results right? So you can use a struct in different library functions that may return a different custom error. Or maybe I am missing something here; but I do believe multiple dispatch is planned f…

Multidispatch traits are being implemented as we speak, and you are correct that this whole discussion is blocked on them (they are mentioned in the first RFC linked, the one discussing `FromError`).

Re: On Error Handling in Rust

#50

Post by steveklabnik »

kibwen wrote: post #48
steveklabnik wrote: post #45

Earlier quoted context omitted.

Rust used to also have Either, and it was changed to Result for the same reasons. Name things what they mean. :)

Funnily enough, we actually used to have both Either and Result, until one day we went through and realized that no code in existence was using Either and decided to go all-in on Result instead.

Someday, we should have a "History of Rust" thing, kinda like folklore.org or something.
Post reply on HN