33 points ibobev 2 hours ago 13 comments

paaloeye 1 hour ago | parent

$curl: (6) Could not resolve host: gracefulliberty.com HN effect?

agumonkey 1 hour ago | parent

paaloeye 1 hour ago | parent

Legend!

LoganDark 1 hour ago | parent

> In Rust you can use ?, which is quicker than unwrap, but you also have to do something like Result<Type, Box<dyn std::error::Error>

No, you don't! When returning Result<T, E>, you can use ? on any Result<T2, E2> where E: From<E2>. In other words E doesn't have to be Box<dyn>, it just has to satisfy From<E2>.

Crates like thiserror make it easy to define your own error types that can be easily converted from all the other error types you can encounter in your functions! I do this whenever it doesn't make sense to use an inner error type directly, or whenever a function does its own validation that deserves its own error variant.

On top of that, I tend to also have error variants for each place in the function rather than only for each type of inner error. At error sites I do something like `.map_err(MyError::PlaceInTheFunction)?` rather than only `?`, and then errors become like a very efficient backtrace :)

Graziano_M 45 minutes ago | parent

I think you're proving the author's point.

tcfhgj 42 minutes ago | parent

how so?

GreenDolphinSys 34 minutes ago | parent

They're saying that you don't always have to return Result<T, Box<dyn Error>>, you can implement the From<Error> trait on the type and use ? as usual.

In other words implementing that trait lets you set a return type like Result<T, CustomAppError> use ? on it.

LoganDark 33 minutes ago | parent

I think they're saying the author's point is that it's more fiddly in Rust (even if there are strong, well-regarded fiddles to use)

Graziano_M 31 minutes ago | parent

Yes, and your other part about the crate.

> There's also Zig-style composable errors with yet another library.

LoganDark 24 minutes ago | parent

Ah, it's behind a link!

While I'd push back against implying From<E2> is part of the crate, thiserror is an idiomatic approach these days, so I can understand the confusion. I can totally see how they could come to favor Zig if this behavior is "the default", as opposed to Rust where you'd usually see it done with "yet another library".

And so I see "the author's point" has another meaning now: that Zig-style errors are good :)

Edit: oh, after looking into Zig-style errors more, this is actually not how they work! They don't nest, they just exist in a global namespace, so they don't come with any location data themselves, but you can compose sets of them. Less powerful, but certainly more appealing to some :) I think out-parameters can be used as a side channel for error context.

Graziano_M 14 minutes ago | parent

Yeah I 1. wish they were properly composable and 2. think Rust would get less flak if these 'idiomatic' crates were just pulled into the standard library to avoid some of the dependency mayhem.

GreenDolphinSys 12 minutes ago | parent

I don't think errors are fiddly in rust. They're easy to compose.

paaloeye 46 minutes ago | parent

Does ReTangled have anything to do with https://tangled.org?