Initializers returning nil cause Typhoon to crash

[rodgutierrez]

I'm using Typhoon to inject an instance of a class that is only supported on certain versions of iOS (it's a wrapper for HealthKit functionality). When this class is instantiated on unsupported versions of iOS its initializer returns nil, which appears to be acceptable behavior. However this pattern is causing Typhoon to crash.

This crash is happening while running Typhoon 2.3.1 in TyphoonComponentFactory on line 379. Here's the error:

2015-01-27 18:08:33.702 Strava[17099:607] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** setObjectForKey: object cannot be nil (key: healthStoreService)'

[jasperblues]

If a valid class has an initializer that returns nil, the question is:

• Should Typhoon fail, as it does now, but with a more meaningful error message, and make the user work-around this?
• Should Typhoon accept this and simply issue a warning that no instance will be injected, since the instance is nil?

Let's try to enumerate cases where:

• the first scenario has benefits that outweigh the 2nd.
• the second scenario has drawbacks that outweigh the first.

If we can't see any obstacles, let's push 2.3.5 with a fix to this within 24 hours. In this case would you like to send a PR? (Simply wrap the injectInstance:withDefinition method in a nil-check)

[jasperblues]

@rodgutierrez I've added the ability for an instance returned from TyphoonComponentFactory+InstanceBuilder to validly be nil. (Actually good timing,k it turns out we needed this today too :) )

To try:

pod 'Typhoon', :head

Once you verify we'll push a new micro version to CocoaPods master.

[rodgutierrez]

@jasperblues This looks great! 👍

Thank you for the quick response.