Remove anyhow and use pure thiserror impl

[0xpr03]

Simulates the anyhow<thiserror> matryoshka for contexts by
implementing this via kind-parent error types.

Closes #7

[0xpr03]

Looking at the details it may be easier to use snafu to get free optional contexts, I'm tried to map your context model onto thiserror, but it's specifically noted that thiserror doesn't come with such a nice .context wrapper out of the box. Snafu does support such context cases, which makes it easier to use but doesn't solve the problem entirely:

The other thing is that you kind of have to use two error types to get a kind and an additional context that can be stacked infinitely from function to function. I kind of simulated this here via FooError and FooErrorKind having a transparent wrapper and a context version.

[jsvana]

I like this overall, but I think it might be cleaner to get rid of Context entirely and instead use more specific thiserror variants. That way we can still get the error message ("failed to read packet ID"), but we get a specific error enum variant (ProtocolError::MalformedPacket(String)). What do you think?

[jsvana]

nit: can you run rustfmt on this?

[0xpr03]

but we get a specific error enum variant
ProtocolError::MalformedPacket(String)

What exactly do you want to store in the String ?

[0xpr03]

I'd try to preserve the original error. If we're looking at the server module we have

.read_packet()
            .await
            .map_err(|e|ServerError::with_context(e, "failed to read response packet"))?;

Which internally also has 3x a context and InvalidPacketId. Which calls also read_varint that also has a specific ProtocolErrorKind::InvalidVarInt and throws for io::Error.

I think you want to preserve all of them in case of an error (or at least the underlying IO error). So you don't end up with only the top level error.
Thus I'd do something like MalformedPacket(#[from] ProtocolError) which contains all the others (and never loose the original error). For the stacked ProtocolErrors its a little bit harder.

Personally I went with snafu adding some high-level contexts in the top function and adding a Backtrace gated behind a feature, so I can backtrace errors when the blackbox of server doesn't behave as expected.

So I think its up to your liking how much detail you want to expose, how you report errors and where you make a cut and don't report the full error chain (not the crate ;) ).

[jsvana]

That's a fair point. Having that context is great. I think my biggest concern here is that it seems like we're rolling context from scratch. I'm not strictly opposed to the solution you have here, but do you figure we'd have less scaffolding code if we just switched this to snafu?

What exactly do you want to store in the String ?

This was just a weak compromise to have a bit of context without the extra scaffolding :)

[0xpr03]

Snafu would allow us to get a context for free (and enforce using a context all the time if we don't add a default conversion). It's a little bit more macro heavy (some people really dislike that, up to you) and we could add an optional backtrace. I'm not sure about a nested context, but it should work.

[0xpr03]

I could give a snafu version a run, but that'll probably have to wait until next monday.