Hacker News new | comments | show | ask | jobs | submit login

> even if it's just to spit out a log/stdout message.

This will print an error out already.

  $ ./target/debug/tokiotest
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 98, message: "Address already in use" } }', ../src/libcore/result.rs:837
Printing out a _better_ error might be helpful, though, I'll agree :) You could use expect for that, which lets you change the message in the ''s easily.

This really shows a fundamental tension though, in documentation. Is this example supposed to be demonstrating error handling? Or just get you going? Does adding more complex error handling distract from the point it's trying to teach? These are sort of open-ended questions.

Wasn't there an attempt to get a variation of main that returned result at one point(that would presumably print error and set exit code one error)? Back before "?"

If rust had that examples would be even shorter using ? Instead of try! or unwrap

FWIW there are third-party libraries which include that feature e.g. error_chain has a `quick_main` macro (working with its `error_chain!`-generated error, but I'm not sure it actually depends on it):

    quick_main!(|| -> Result<()> {
        // insert Result-returning code here
Alternatively it takes a few lines to bootstrap it by hand e.g. ripgrep uses this code to bootstrap:

    fn main() {
        match Args::parse().map(Arc::new).and_then(run) {
            Ok(0) => process::exit(1),
            Ok(_) => process::exit(0),
            Err(err) => {
                eprintln!("{}", err);

Yes, and that discussion is still ongoing. The devil, as always, is in the details.

`-> impl Trait` seems useful in that context, so that main could have a variety of appropriate return value types: `()`, `i32` (for an exit code), or `Result<T, E>` where T implements ReturnValue and E implements Error.

`quick_error` uses a trait like that to determine the exit code of `main()`, allowing it to return either () or i32.

The output of panic! seems to be useful only to the programmer, not the user. As a user, getting an error message like that would lead me to think that the application is defective, as it arguably is if it cannot provide better user experience in a completely expected error condition like a port being already in use.

The output of panic will only ever be seen by the programmer. Unwrap exists to ease prototyping and to make simple code examples. IME, the first thing you do when you take a Rust application from the prototype phase to the production phase is to grep for unwraps and insert proper error handling.

> The output of panic will only ever be seen by the programmer.

Obviously not if it's used for input errors (network failure). Crashing assertions are made for bugs, not input errors.

Please read the rest of my comment. It's not used for input errors.

This is invalid since nothing in the compiler forces you to remove the .unwrap() so it's safe to assume it will not be done before production. The whole "but this is just for prototyping" is a logical fallacy, as you know we have tons of prototypes in production ;)

I admit that I'm having a hard time seeing this criticism as anything but overblown. Finding usage of unwrap is trivially easy via textual search. Furthermore, Clippy can be used to automatically forbid usage of unwrap for your entire team ( https://github.com/Manishearth/rust-clippy/wiki#option_unwra... ). Furthermore, even when you hit a panic, it tells you which line of code in which file triggered it so that you can fix it immediately. Furthermore, the Rust community has a strong and long-entrenched proscription against libraries which unwrap rather than handle errors.

We can agree in the cynical interpretation of the laziness of programmers, but the mitigations in this case are so trivial, and the stakes so low, that focusing on unwrap as a point of contention is a poor use of energy.

Absolutely. Your users aren't likely to be seeing a server-side process like this fail, though, so in this situation, seems fine.

As I said in the post you're replying to, a nicer error message would be a good thing.

> Your users aren't likely to be seeing a server-side process like this fail, though, so in this situation, seems fine.

Whoever maintains the server and runs the service is also my user, though, in the general case.

> As I said in the post you're replying to, a nicer error message would be a good thing.

Yeah - I don't mind if unwrap panics with a dev-oriented message as it's basically an assertion, but I guess I expected expect() (no pun intended) to give a more user-friendly error. Maybe the format of the panic! output could be changed to bring the message to the front and the technical details after that.

In the world of server systems programming once an organization gets beyond a certain size it's uncommon to have programmers administering server daemons or other server applications. Those folks are indeed users.

See my sibling comment to the above. By the time your software has matured enough that it's been deployed to non-developers, unwraps have no place in the code. It's not an error-handling strategy, it's just "// TODO: Add error handling" that the compiler understands.

Example code should be exemplary.

As I said elsewhere, exemplary of what? The concept, or robust error handling? Even with the latter, it's unclear what the _right_ error handling is without knowing what you're actually doing.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact