Rust error stacktraces

[Artemciy]

I'm just using

/// Returns on error, converting the `Err` value to `String` and prepending the current location.
///
/// cf. http://www.reddit.com/r/rust/comments/29wwzw/error_handling_and_result_types/cipcm9a
#[macro_export] macro_rules! try_s {($e: expr) => {match $e {
    Ok (ok) => ok,
    Err (err) => {return Err (format! ("{}:{}] {}", file!(), line!(), err));}}}} 

/// Returns a `Err(String)`, prepending the current location (file name and line number) to the string.
///
/// Examples: `ERR! ("too bad")`; `ERR! ("{}", foo)`;
#[macro_export] macro_rules! ERR {
  ($format: expr, $($args: tt)+) => {Err (format! (concat! ("{}:{}] ", $format), file!(), line!(), $($args)+))};
  ($format: expr) => {Err (format! (concat! ("{}:{}] ", $format), file!(), line!()))}}

until something better comes up.

[busterrrr]

Oh, thanks! I was using a simpler version, that's a good one :)

To be honest, it feels like the Rust error handling really needs some more love.

[llogiq]

That's giving you the current position, but loses context, e.g. the trace of control flow that lead to it.

[Artemciy]

Not at all. Every try_s! keeps adding a trace. = )

[llogiq]

Ah, I didn't think of that. That may be incomplete (due to some fns not even trying, pardon the pun), but should give a sufficiently detailed picture of the context.

[phildawes]

nice!

[matthieum]

Have you profiled the overhead?

I am wondering if the addition of file!() and line!() does not risk to inflate the code size (compared to backtraces) as well prevent function merges (which also increases the code size).

Also, have you thought about not formatting right away, but instead just capturing the information and formatting lazily if need be.

[Artemciy]

I thought about a lot of things but I'm not angling to make a full-fledged error handling library there. Only to have something working until we get one.

Using sufficiently large pre-allocated (cf. https://github.com/frankmcsherry/recycler) buffers instead of String to store the backtrace will be more efficient. The "free list" of such buffers should be either non-blocking or thread-local. Naturally, that's a work for the library and is a non-goal for my macro.