Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm willing to accept that argument for unwrap, makes sense if you're dealing with a situation where multiple errors can apply.

Outside of unwrap, which actually crashes out, is it not possible to access the stack trace? Forgive my ignorance, I've never worked in Rust nor any other on-the-metal languages before!



In Rust there generally isn't a stack trace, because you generally can know where the error comes from. What you get for an error depends on what is giving you the error. Generally you get an enum with the general error type, and maybe a way to access the specific error.


> In Rust there generally isn't a stack trace, because you generally can know where the error comes from.

I don't understand. Does that mean that there's sometimes a stack trace? Why would it matter if you had other ways to know where the error comes from? Surely you could say the same thing for the majority of programming languages.

Sure, Rust can wrap errors via the type system, but I don't think that's a compiler-level guarantee. Maybe it's just a language design decision, then?

> Generally you get an enum with the general error type, and maybe a way to access the specific error.

That seems odd to me! Is the presence of a pointer to an error object something that's implementation-specific? If so, is it not typically done in the standard library? As far as you can speculate, what's the design justification for that?


> Does that mean that there's sometimes a stack trace?

Yes. There's a bunch of different bits that come together to cause this, but the core of it is roughly that keeping stack traces adds a cost that not everyone is willing to pay at all times. Rust is trying to figure out how to best accomplish good error handling in an environment that doesn't provide easy answers like "just do it like x at all times."

> Is the presence of a pointer to an error object something that's implementation-specific?

To use the Go parlance, errors are values in Rust. They're not inherently special. There is an interface you can implement if you want interoperability, but Rust only gives you the ability to interoperate, it cannot force you to.


Error traces are generally only on panic. Rust does not have exceptions, and errors must generally be handled where they can occur.

Error context is implementation-specific. This is partially because Rust is a young language, and the best-practice API hasn't really been figured out yet.


I think the other replies are a bit confusing. unwrap causes a "panic" - panics in rust are similar to python exceptions, but it's not catchable. (there actually is a way to catch panics because that's how the stacktrace printing is implemented, but you usually only use it if you're making a custom allocator or runtime or some other voodoo magic)

So if you want your "exception" to be able to be handled by the caller, you have to indicate it otherwise, usually with enums.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: