Handling NSErrors returned from factory methods that produce errors.

[fatuhoku]

By using -withFactory:selector: it's possible to invoke factory methods that throw errors. e.g.

- (MESFooBar *)foobar {
    return [TyphoonDefinition withFactory:[self foobarFactory] selector:@selector(foobarWithError:)]; // ...
}

The question is, how can the error be processed if it arises?

[alexgarbarev]

First of all, use HEAD version of Typhoon. (Recently I did minor change to get this feature working)
Then change your assembly like that:

- (MESFooBar *)foobarWithError:(NSValue *)error {
    return [TyphoonDefinition withFactory:[self foobarFactory] selector:@selector(foobarWithError:) parameters:^(TyphoonMethod *factoryMethod) {
               [factoryMethod injectParameterWith:error];
           }]]; 
}

NSValue with pointer would be unwrapped (old Typhoon feature to unwrap non-object values) for method invocation

Option 1 (Explicit ownership rules on caller side)
Method declaration:

- (MESFooBar *)foobarWithError:(NSError **)error

Caller:

__autoreleasing NSError *error = nil;
MESFooBar *foobar = [self.assembly foobarWithError:[NSValue valueWithPointer:&error]];
if (error) {
    // error handling
}

Option 2 (Explicit ownership rules on factory method side)

Method declaration:

- (MESFooBar *)foobarWithError:(NSError *__strong*)error

Caller:

NSError *error = nil;
MESFooBar *foobar = [self.assembly foobarWithError:[NSValue valueWithPointer:&error]];
if (error) {
    // error handling
}

IMPORTANT NOTICE
You have to be careful with ownership rules. ARC can't handle this case implicit, because it's too complex for ARC (object written by reference wrapped by NSValue). So you have to use explicit ownership rules:

• if NSError on caller side is strong (have __strong attribute or empty), then factory method declaration must be like (NSError __strong)
• if NSError on caller side is autoreleasing (have __autoreleasing attribute), then factory method declaration must be like (NSError __autoreleasing) or (NSError **)

Otherwise you'll get the crash

[jasperblues]

@alexgarbarev Looks like tests are failing since last commits.

[alexgarbarev]

@jasperblues, yes, reverted back. This failure related to #325 - not this ticket

[alexgarbarev]

I think we should update documentation for that common case (just faced with that and had to search for that ticket)