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

Scala gets stack traces automatically from the JVM though, along with much of its debugging support. The Rust team will have to do this all by themselves, being a natively compiled language and all.



You can get stack traces on panics by running with RUST_BACKTRACE=1.

I don't know that it makes much sense on Error objects though, there's no requirement that they're even able to store backtraces, and collecting backtraces any time an error object is created would be really expensive and would make the runtime a dependency of errors.


Most VMs put most of the overhead of stack creation at where the error is created, so it usually works out fine (throw is expensive, everything else is cheap). Stack traces are usually dependent on whatever debug symbols are loaded, so in the CLR you'll get huge blank spaces if an exception propagates through some dynamically generated or even native code.

Just printing stack traces is a distraction though. The only thing that is required that on an exception, the entire stack above the the exception site can be inspected in the debugger.


That's a completely different concern, and it only makes sense on panics, not any time an Err result is created.


And how do you tell where an error originated without a panic being called? Is the programmer expected to just instrument the their code to put the panic in as soon as possible? Anyways, this is a well-known problem with monadic error handling, and one of the main reasons it doesn't get more widespread adoption.


Sure. The author mentioned lack of stack traces as a downside of the technique. I wanted to clarify this was Rust specific (and likely to change).




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

Search: