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

Using ChainedError generically #100

Closed
withoutboats opened this issue Dec 23, 2016 · 1 comment
Closed

Using ChainedError generically #100

withoutboats opened this issue Dec 23, 2016 · 1 comment

Comments

@withoutboats
Copy link

Hey there, I'm writing another library, which needs users to be able to define their own errors and compose them with other users' error types. I was hoping simply requring users to define their errors with error-chain would solve this problem, but I'm having some trouble.

Specifically, I'd like:

  1. E: ChainedError gives me a way of performing a conversion for<F: ChainedError> F => E. That is, I can convert any ChainedError into any other ChainedError. Though the library may generate specific impls that enable this (seems like the ResultExt does this), there's no trait abstraction of this operation allowing me to deploy it in a generic context.
  2. The same thing, but for<F: std::error::Error> F => E. That is, I can convert any Error into any ChainedError. This may be trickier, of course, because it may require creating a Box<Error>, and may be less preferential than explicit links for this reason (though I sort of don't agree that avoiding dynamic dispatch in the error path is significantly beneficial).

Is it possible for either of these to be provided? Unfortunately orphan rules prevent any impl of From<X> for T: ChainedError, and without HRTB of types you can't bound ChainedError: for<X> From<X> either. But even if I had to be explicit, that would be better than being unable to do it.

@withoutboats
Copy link
Author

Nevermind, I've figured out how that I can solve this by being explicit about the From bounds where I need them.

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

No branches or pull requests

1 participant