You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 24, 2021. It is now read-only.
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: