-
Notifications
You must be signed in to change notification settings - Fork 14
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
expose error types #5
Comments
grenewode
pushed a commit
to grenewode/chrono-english
that referenced
this issue
Nov 1, 2018
Makes the error types public so that external crates can access them. This makes it easier to work with this crate safely, as otherwise errors cannot be analyzed by external crates. Possible resolution to stevedonovan#5
Closed
I'm also having issues with this. This pull request is from my fork where I have this fixed for my own usage, but all the tests pass and it seems to work. |
stevedonovan
pushed a commit
that referenced
this issue
Nov 4, 2018
Sounds like a reasonable and easy thing to do! 0.1.4 has just been published exposing DateError and DateResult. |
Thanks @stevedonovan |
Thanks! Closing my pull request as well. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
the main signature of this create returns an error which is public but not exposed by a path external to this crate - https://docs.rs/chrono-english/0.1.3/chrono_english/fn.parse_date_string.html
this could be fixed if the errors mod was exposed as
pub
( the default is private )it's sometimes conventional to re-expose a type inside a package like errors at the top level of the crate with something like
pub use errors::{DateResult,DateError}
.I'd be happy to submit a pul but I wanted to see what you thought first
The text was updated successfully, but these errors were encountered: