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…
On Error Handling in Rust
11–20 of 82 posts
Re: On Error Handling in Rust
#12I 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?
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
#13For 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.
Re: On Error Handling in Rust
#14I 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…
Re: On Error Handling in Rust
#15Wow, 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.
Re: On Error Handling in Rust
#16For 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#
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
#17Re: On Error Handling in Rust
#18Wow, 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.
Re: On Error Handling in Rust
#19So 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?
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
#20Either 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.