Hacker News Reader

Comment by lisivka | Hacker News Reader

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.

View on HN

  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.

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.

Reply on news.ycombinator.com