Introduce proper error handling

[MattesWhite]

Use Case:

There should be a more precise error reporting than everything being an io::Error. While sure a lot of possible errors are due to IO there are also errors that come from misuse of the NATS protocol, e.g. a malformed subject, and errors from third-party crates like crossbeam or tokio.

Proposed Change:

Create an own error types, following state of the art error handling, with a crate like thiserror. In some places, replace Options with a Result to give a better understanding what went wrong. Also errors from third-party crates could be layered in the own error types giving more context what caused failure.

Who Benefits From The Change(s)?

In general all users of this NATS client as a more detailed error reporting makes debugging failures easier. Even application users benefit as they can give more precise feedback.

Alternative Approaches

You could stay with io::Error, however, as the crate grows you will probably end up writing a lot of

return Err(Error::new(
    ErrorKind::Other,
    "Something went wrong!",
));

and the longer you wait to introduce proper error types the more work it will be to fix it.

---

If you need further advice or other help I'll be glad to help.

MAYBE I find the time to write a PR myself.

[spacejam]

Hi @MattesWhite, thank you for opening the issue. This has been extensively discussed over time, and we feel that the current approach of using io::Result minimizes user friction without loss in specificity of error handling. While there are some cases of ErrorKind::Other, these are likely to be encountered early in the dev process and among the runtime errors that users need to handle days, weeks, and months after deploying, there is near total 1:1 overlap likely between the specificity of io::Error and the actual runtime issues encountered while interacting with a NATS server.

[caspervonb]

Closing as stale. We've been moving to concrete error types for async-nats.