Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error handling without anyhow #22

Open
xorpd opened this issue Nov 29, 2021 · 3 comments
Open

Error handling without anyhow #22

xorpd opened this issue Nov 29, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@xorpd
Copy link

xorpd commented Nov 29, 2021

Hi, thank you for writing this library!

I noticed that most of the exported API functions in this library return anyhow results.
Being new to the rust error handling ecosystem, I was wondering if as an application developer I will also have to use anyhow to handle errors, or will I still be able to use the traditional Result<>, like I have always done.

I have been searching for a Rust library that could help me with XMR payment processing, and this library seems like on of the only options, so I will probably use it anyways (: But I am asking ahead of time just to know if I will have to make some compromises with the rest of my application code.

Thanks!

@xorpd
Copy link
Author

xorpd commented Dec 2, 2021

Hey, I came back after learning a bit about anyhow.
I read this sentence on anyhow's project readme:

Use Anyhow if you don't care what error type your functions return, you just want it to be easy. This is common in application code. Use thiserror if you are a library that wants to design your own dedicated error type(s) so that on failures the caller gets exactly the information that you choose.
(https://github.com/dtolnay/anyhow#comparison-to-thiserror)

If we want monero-rpc-rs to be a library used by rust applications, maybe it could be a good idea to use something like thiserror?

@h4sh3d
Copy link
Member

h4sh3d commented Dec 2, 2021

Interoperability wise it is better for a library to use thiserror IMO, as it doesn't impose a dependency on downstream projects. But I don't know the rational of @vorot93 when this was first created, nor if/when we would consider a switch from anyhow to thiserror.

@h4sh3d h4sh3d added the enhancement New feature or request label Jun 29, 2022
@h4sh3d h4sh3d added this to the v0.2.0 milestone Jun 29, 2022
@h4sh3d h4sh3d modified the milestones: v0.2.0, v0.3.0 Aug 1, 2022
@h4sh3d h4sh3d removed this from the v0.3.0 milestone Dec 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

3 participants