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

expression::Error is private #99

Closed
CryZe opened this issue Jan 2, 2017 · 5 comments
Closed

expression::Error is private #99

CryZe opened this issue Jan 2, 2017 · 5 comments
Labels

Comments

@CryZe
Copy link

CryZe commented Jan 2, 2017

This is unfortunate because now there's a private type in the public Expression trait that I can't implement From<expression::Error> for.

Update: It kind of works if you chain multiple into calls together. Still kind of bad if you wanted to use try! or the question mark operator, as that's completely impossible with the current situation.

@shepmaster
Copy link
Owner

Yeah, I recently ran into something like that in my toy program to exercise things. In my case, I changed my function to something like fn foo<E>(x: Result<Blah, E>) where E: std::error::Error, which allows you to do certain things but not everything.

My main concern is that I don't really want the enum variants to be part of the public API, as I'd like the flexibility to change them...

@CryZe
Copy link
Author

CryZe commented Jan 2, 2017

You can also just change the trait definition to use the public Error type.

@shepmaster
Copy link
Owner

the public Error type.

But that type also refers to expression::Error; wouldn't that cause the same problem for you?

@CryZe
Copy link
Author

CryZe commented Jan 2, 2017

I meant sxd_path::Error. That one is public, so I can write a From<sxd_path::Error> impl for that. I just want to encapsulate it into my type, so that would just work.

@shepmaster
Copy link
Owner

I meant sxd_path::Error.

The downside of reusing that is that just evaluating the XPath can't cause a "missing XPath error", so there would be error types that could never happen. I've a PR up that adds opaque wrappers for the specific error types without exposing the internals.

As a heads-up, I've done some reworking of the library, so 0.4 is going to entail some changes! 😇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants