Trouble getting basic example working about snafu

[mikeando]

Yeah, the only remaining thing is available time...
Hopefully some of that will free up and I'll be able to start looking at this side of things again.

Thanks,

[shepmaster]

struct `CatchAllError` is private

This one is a "known issue" that I... forgot to make known. I'd love it if you could chime in on #28 with what your specific use case is and how you'd like to control this.

---

the trait bound `error::SeparateError: From<snafu::Context<io::Error, error::CatchAllError<&str>>>` is not satisfied

There's also this part of the error, mentioning NoneError:

   = help: the following implementations were found:
             <LocalError as std::convert::From<snafu::Context<snafu::NoneError, CatchAllError<T0>>>>

It looks like you haven't declared a field to store the underlying error source in your error enum:

pub enum SeparateError {
    CatchAllError { mesg: String },
    // ^ No `source: ...`
}

Changing to

CatchAllError { mesg: String, source: std::io::Error },
//                                    ^~~~~~~~~~~~~~

Should fix that issue.

[mikeando]

Ah, I actually remember reading that somewhere, that the contexts only work if the type contains a source field.

I guess that users can work around that by using something like.

with_io_error().map_err(|_| error::CatchAllError{mesg:"Eeek an error!"}.into() )?;

I'm not sure the compiler is smart enough to do that without a turbofish or explicit type annotation though...

I do wonder if uniformity might be valuable here though - I can imagine wanting to remove the source field in non-debug builds in tight-loops or resource-constrained situations. It would be nice if that was just a change to the enum definitions and not every call-site. But I'm not sure how that could be done in a way that prevents users from doing dumb things.

As for the #28 case, I agree that having correct errors per-component would be best. This was mostly in transitioning code from using a more ugly general error case towards snafu, with the end goal of cleaning up the error handling in each component, but not wanting to make that level of change in one hit.

I guess the right way to approach that kind of change is to work from the leaves up, keeping the high-level error handling using the ugly general stuff to start with and migrate components to their own error types one-by-one.

But I think having the ability to make the contexts public would make this kind of transition easier, and allow more options for how the users use this library.

[shepmaster]

work around that by using something like

Another possibility would be to explicitly discard the error first:

with_io_error().ok().context(error::CatchAllError { mesg: "Eeek an error!" })?;
//             ^^^^^ Now an `Option`

That could even be made into a set of functions on ResultExt, but I kind of like the composability shown here.

[shepmaster]

remove the source field in non-debug builds

Is this a need you have, or are you just thinking aloud about the possibilities?

[shepmaster]

and allow more options for how the users use this library

Yeah, this is always a tricky aspect — deciding how flexible to be without becoming a junk drawer of every possible permutation and without a clear sense of purpose. However, I don't see allowing customization of the visibility to be outrageous.

[mikeando]

remove the source field in non-debug builds

Is this a need you have, or are you just thinking aloud about the possibilities?

It's not something I need for my current rust projects. So it's mostly thinking aloud. But I live in two worlds - and my non-rust world is primarily HPC, where every byte and every cycle can count - and we do some tricks in our C/C++ to change error handling between release and debug builds - and there are definitely hacks to avoid changing every call-site. (I'd love to use rust for my HPC stuff - but that's not yet an option due to politics, legacy code, platform requirements etc.).

[mikeando]

Another possibility would be to explicitly discard the error first:

With the new changes to OptionExt, that is certainly a neat way to handle it.

I think maybe a section in the docs with a bit more detail on the Contexts and where they're valid to use (with examples) would be good. I'll try and see if there's something I can add tonight, if you like.

[shepmaster]

something I can add tonight

Absolutely, that would be wonderful! I want to add a bunch of documentation and then make a pass through to organize and curate it.

[shepmaster]

remove the source field in non-debug builds

Without actually trying it out, I have a feeling that this would already be possible with the current tools and a little bit of custom traits. I'll go ahead and spin that enhancement suggestion to #30

[shepmaster]

Is there anything else preventing your use of this crate?