> I'm sure Rust will get similar utilities with time.
Unlikely. Scala gets tracebacks for Try because the left arm stores a JVM Throwable, and throwables reify a stacktrace during initialisation.
For Rust, this would mean:
* Result's Err mandates an Error (currently has no trait bound at all)
* Errors must be able to store a traceback
* Error/Result requires rt in order to collect a stacktrace
* Rather than stack-allocating a struct or two, Err results now require significant heap allocation and data collection completely breaking existing usage patterns
I'm not suggesting `Err` stores a backtrace. I am suggesting that the programmer could choose to store a backtrace in the error objects they choose to store in an `Err`.
I don't do this in my Scala code because I rarely find I need a backtrace.
This will collect a stacktrace in the provided buffer, the result can then be stored in whatever object the developer wants (likely after decoding it to a String): http://is.gd/tOD8Ho
Note that you really don't want to be relying on this unstable feature, it's quite a hack at the moment and will very likely be moved out into an external crate.
As long as Err results are only created under exceptional circumstances, there should be no performance hit right? This is one significant reason why errors should get a path separate from normal return values, but that isn't the case in Rust (or monadic error handling in general, which doesn't really consider debugging).
Unlikely. Scala gets tracebacks for Try because the left arm stores a JVM Throwable, and throwables reify a stacktrace during initialisation.
For Rust, this would mean:
* Result's Err mandates an Error (currently has no trait bound at all)
* Errors must be able to store a traceback
* Error/Result requires rt in order to collect a stacktrace
* Rather than stack-allocating a struct or two, Err results now require significant heap allocation and data collection completely breaking existing usage patterns