-
Notifications
You must be signed in to change notification settings - Fork 72
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
Throwing factories and resolve dependencies block #32
Conversation
@@ -186,28 +186,30 @@ public final class DependencyContainer { | |||
Though before you do that you should probably review your design and try to reduce the number of dependencies. | |||
|
|||
*/ | |||
public func resolve<T, F>(tag tag: Tag? = nil, builder: F->T) throws -> T { | |||
public func resolve<T, F>(tag tag: Tag? = nil, builder: F throws -> T) throws -> T { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if the outer throws
should be throws
or rethrows
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here rethrows
will not compile cause this method throws error itself.
Just make sure you double-check every time you use |
Note: once you merge that, make sure to rebase #13 before merging it, as I'm wondering if this change might have impacts on the playground / example code you added there too, like changing calls using |
Looks like |
👌 |
Good catch, these changes actually broke #13 😞 will try to figure out the fix |
Fixed the issue, it is safe to merge this now 🎉 |
Throwing factories and resolve dependencies block
With that PR we no more need to call
container.resolve()
withtry!
inside a factory orresolveDependencies
block. Also convenient to use throwing constructors or any other throwing methods inside those blocks. Error will be catched by container, printed in console and then will be re-thrown.Note: There is no way (at least for now) I can think of to be able to distinguish between throwing and not-throwing factories (thus the latest definition will override previous), except of duplicating all
register
/resolve
methods, what I don't like at all cause it will double the number of methods in container. Taking in account that tag is an optional argument and we have support for 6 runtime arguments already (and upcoming multi-injection feature will ad 6 more methods) it will make API too much bloated.