Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

Exactly. It isn't just that it's shorter; it fixes a right-left-right-left alternating reading order, turning it into a left-to-right reading order.

View on HN

I think it also lets you turn this:

    try!(baz(try!(bar(try!(foo())))

into

    baz(bar(foo()?)?)?

Which isn't as bad as the alternating order for chained evaluation, but cleans up a lot of the noise.

True, though in some cases you may want to write that one as:

    foo().and_then(bar).and_then(baz)

That becomes a bit more verbose, but it reads left-to-right, and works better if you want to use a closure as one of the functions. Which form looks more readable in a given circumstance may depend on the nature of foo, bar, and baz.

It has somewhat different semantics though, for instance with `?` all three functions can use different error types.

They have to be convertable though, because the function must have a single result code.

What if I want to do something like in following snipet:

    baz(foo)?("Cannot do baz, foo={}", foo).bar()?"Cannot do bar";

Is there a syntax sugar for such thing? If so, I will be converted to Rust.

It would work with just the ?s if you had the right implementations of the error conversion functions. I have an example below.

Compiler cannot determine intent, so it will not be able to produce correct, user readable error message, in user language.

Yes, that's why you end up writing an error type and the conversions between various errors.

Imagine, you are taking exam.

If you found incorrect question in exam, then it is a bug.

If you answered all questions but wrongly, then it is a failure.

If you answered correctly to all answers but examiner said that you failed, then it is an error.

In case of bug, code must panic.

In case of failure, code must return a result, which clearly says that this is the failure. Try next time.

In case of error, code must print informative description of error, bunch of data, and maybe some hints to operator, so he will be able to fix it.

We are talking about errors, right? Why I need conversions to display bunch of strings with descriptions and variables to an operator? Just let me collect strings and print them to a log.

> Just let me collect strings and print them to a log.

If that's something you want to do, that's quite easy. Vec<String> is your error type. Done.

But if you want to build something a bit richer, for example, to differentiate between the case in which you answered a question wrong, or when the examiner fails you, you could do that as well. It all depends.

But errors as values is what allows you to have that flexibility; it's easily extensible.

Thanks you, I got the idea.

  baz(foo).expect(format!("Cannot do baz, foo={}", foo)).bar().expect("Cannot do bar");

Where you found this expect() function and how it will receive error, generated by baz? I read Rust documentation about error handling multiple times, but newer saw adequate error handling.

The best solution I know is error-chain library:

    use errors::ChainErr;
    try!(do_something().chain_err(|| "Something went wrong"));

https://doc.rust-lang.org/stable/std/result/enum.Result.html...

Panic will stop program at place of error, while I want nicely stacked error message list:

    [reports.rs:25] ERROR: Cannot write report "Foo" to file "foo.xml".
    [templates.rs:125] ERROR: Cannot process template "header". Check is template file exists and readable.
    [fileio.rs:45] ERROR: Cannot open file "/usr/share/foo/templates/header.tmpl": unable to enter directory "/usr/share/foo". Check directory permissions.

Instead of

   writing report cannot open file done

It saves lot of time(money) in production.

Has anyone suggested some sort of postfix macro syntax? I don't have one in mind, but perhaps there is some nice looking, viable one. That might have been a more general solution than a new operator.

> Has anyone suggested some sort of postfix macro syntax?

Yes, numerous people. A few different discussions have gone by; it has many potential applications, but it introduces several aspects of syntactic weirdness and parsing weirdness, so it'd require a lot of care to introduce if at all.

Reply on news.ycombinator.com