Hacker News Reader

Comment by tills13 | Hacker News Reader

why does _literally_ every line start with "try"?

~$ curl https://raw.githubusercontent.com/ziglang/zig/7cf2cbb33ef34c... 2>/dev/null | wc -l 541 :~$ curl https://raw.githubusercontent.com/ziglang/zig/7cf2cbb33ef34c... 2>/dev/null | grep '^[ ]try' | wc -l 114
541 != 114

Did you mean figuratively*?

* every substantive line

I mean if the OED allows for a metaphorical or hyperbolical meaning, I think you're fighting a literal uphill battle.

No, I clearly meant "literally"

Don't be a pedant.

It's not literally every line, but `try` means "unwrap the error union result or pass the error back up to the caller". It's roughly equivalent to Rust's `?` operator (although Rust's can also unwrap optionals or return `None`)

It makes it obvious that those calls can fail. Every single write to disk, network or malloc can in theory fail. This just makes it obvious that some code needs to handle those edge cases (or, ykno, you can pass them on to the human user).

Not just in theory, they can, and do, fail in practice.

Agreed. Poor choice of word there.

In addition to the other answers, this is the most logical way to handle most errors in this specific type of code. The http code in the Zig standard library doesn’t know how the programmer wants to handle all the errors, so it uses try to bubble up any error it doesn’t know how to handle.

Why so many uses of try? Because Zig is all about readability, and anytime you see try you _know_ that the called function can possibly fail.

Rust used to use the word try in a similar context, but was considered too noisy, and opted for ? instead, which I think worked out very well in practice.

Also, a postfix operator fits nicely with method chaining.

welcome to networking, where every operation can fail

Same meaning as the Rust “?” operator.

Rust's ? is the Try operator, which is currently contemplating Try::branch() to produce a ControlFlow and then if the ControlFlow is Break it returns whatever is inside the Break.

Historically ? was just doing what try! did but while that's equivalent to the current behaviour for Result, there are several more implementations of the Try trait today (and in nightly you can implement it on your own types)

A lot less verbose than “if err != nil { /* 2-3 lines */ }” after every substantive line.

More like `catch |err| return err` so not that big of a saving but yeah it's more convenient

What are you doing with lines 1 and 2? Most people just `return fmt.Errorf("stuff the caller can't know: %w", err)` and call it a day. To me, this beats exceptions because a human can provide context; what iteration of the loop were we on, what specific sub-operation failed, etc.

Spending a lot of time typing in error handling code seems OK to me. You are never going to get paged when your software is working. So you'll probably spend more of your time dealing with rare error conditions. Thus, the code spends a lot of lines capturing the circumstances around the error conditions, so you can go change a line of code and redeploy instead of spending 6 months debugging.

I don't think they're arguing that exceptions are better, just that `try` (in Zig) or `?` (in Rust) is nicer than `if err != nil { ... }`. It's the one thing about go that I really wish had better ergonomics.

A middle ground between exceptions in c++ and checking every function call for an error code in c.

In Go, every line would start with "if". In Rust every line would end with "?".

I find the anti-exception attitude of newer languages questionable.

Reply on news.ycombinator.com