Skip to content
This repository has been archived by the owner on Aug 24, 2021. It is now read-only.

Error Handing User Story #68

Open
jamiebrynes7 opened this issue Feb 9, 2019 · 1 comment
Open

Error Handing User Story #68

jamiebrynes7 opened this issue Feb 9, 2019 · 1 comment
Labels
✨ feature New feature or request 🔎 investigation Further information is required

Comments

@jamiebrynes7
Copy link
Owner

Error handling needs to be fleshed out in the SDK crate - most places use Result<T, String> as the result type - which is fine for debugging purposes, but we likely will want to build a proper error type which users can match on.

Do we use crates like failure, or is that too heavyweight for the size of the project?

@jamiebrynes7 jamiebrynes7 added ✨ feature New feature or request 🔎 investigation Further information is required labels Feb 9, 2019
@randomPoison
Copy link
Collaborator

This article from BurntSushi is still probably the best resource on error handling best practices. Essentially, we want to provide our own concrete error type(s) whenever returning an error. The Error trait in the standard library was fixed semi-recently, so it makes sense to define our own custom error type and implement Error for it. The best crate I can see currently for doing that is err-derive, which extracts the custom derive logic from failure and applies it to the std Error trait. Using that, we could create our own custom error types while still doing so in a way that's compatible with the rest of the Rust ecosystem. err-derive in combination with the derive_more (which provides the ability to derive From impls) would make it really easy to build custom error types.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
✨ feature New feature or request 🔎 investigation Further information is required
Projects
None yet
Development

No branches or pull requests

2 participants