Live data from Hacker News

On Error Handling in Rust

lucumr.pocoo.org

11–20 of 82 posts

Re: On Error Handling in Rust

#11

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…

Doesn't multiple dispatch require run-time type analysis? If so wouldn't that go against Rust's philosophy of zero-cost abstractions?

Re: On Error Handling in Rust

#12
post #11

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…

Doesn't multiple dispatch require run-time type analysis? If so wouldn't that go against Rust's philosophy of zero-cost abstractions?

nope, its all compile time. its just that instead of deciding which impl to pick based upon information X, youre using a pair of pieces of information (X,Y)

Edit, also I think the "convertable" class idea is nearly expressible using associated types in rust today,but im not 100% certain about that

Re: On Error Handling in Rust

#13
post #2

For those who don't closely follow the topic of language design, error handling is actually a fascinatingly diverse subject. Exceptions are not the end of the story, and it's great to see languages explore this space. Microsoft's upcoming M# language has also teased an interesting approach to error-handling. I'm very curious to see what they come up with.

What is it? I never heard of M#

Re: On Error Handling in Rust

#14

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…

You may be in luck: http://smallcultfollowing.com/babysteps/blog/2014/09/30/mult...

Re: On Error Handling in Rust

#15
post #3

Wow, I really, really like that `?` operator idea. I haven't quite dived into Rust yet (I'm watching and waiting for v1.0), but I would be really excited to work with a language that makes error handing so easy and safe.

No need to wait. You can dive in right now without losing much later (I think changes between now and 1.0 aren't going to be that drastic). The guides are really good.

Re: On Error Handling in Rust

#16
post #13
post #2

For those who don't closely follow the topic of language design, error handling is actually a fascinatingly diverse subject. Exceptions are not the end of the story, and it's great to see languages explore this space. Microsoft's upcoming M# language has also teased an interesting approach to error-handling. I'm very curious to see what they come up with.

What is it? I never heard of M#

It was heavily discussed last year.

http://lambda-the-ultimate.org/node/4862

http://joeduffyblog.com/2013/12/27/csharp-for-systems-progra...

Is a variant of C# targeted for systems programming, developed at Microsoft Research. It remains to be seen if it will ever be made public.

Re: On Error Handling in Rust

#18
post #3

Wow, I really, really like that `?` operator idea. I haven't quite dived into Rust yet (I'm watching and waiting for v1.0), but I would be really excited to work with a language that makes error handing so easy and safe.

You could try Haskell.

Re: On Error Handling in Rust

#19
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 denotes, a value which may or may not be present (e.g. an optional field in a struct).

Re: On Error Handling in Rust

#20
Wow, these things would be great! I have been working with database connections, and they feel pretty awkward right now because there are so many opportunities for errors.

Either or both of these would be very appealing.

I remember asking on IRC a few times to see if I could get some interest. One of the things I proposed was a postfix operator in place of try, so I'm pleased to see something like that appear.

For some reason it just really bothered me to see all of my statements begin with "try!" rather than what they are actually intended to do. The "?" could be a great help.

Post reply on HN