Error/Exception handling in a method that returns bool

Question

In my custom framework, I have a method like the one shown below which fetches value from dictionary and converts it into BOOL and returns the boolean value.

- (BOOL)getBoolValueForKey:(NSString *)key;

What if the caller of this method passes a key that does not exist. Should I throw a custom NSException saying key does not exist(but throwing exception is not recommended in objective c) or add NSError parameter to this method as shown below?

- (BOOL)getBoolValueForKey:(NSString *)key error:(NSError **)error;

If I use NSError, I will have to return 'NO' which will be misleading since 'NO' can be a valid value of any valid key.

if you use NSError, ofcourse you return NO, and also you return something via NSError, and based on this you can tell user if something goes wrong or not. Incase of returning YEs, you set NSError as nil, and incase of NO if key exists you set NSError as nil, and if no key exists you return NO, and you send valid NSError object. — Teja Nandamuri, Oct 18 '16 at 15:08
Alternatively, you could choose to return the value in an `NSNumber` wrapper (i.e. return `@YES` or `@NO`), with a `nil` return value if it was not found. The caller can then check to see if the value was `@YES` or `@NO`. This might not necessarily fit with your design, but it's as close to an optional `BOOL` as you can really get in Objective-C efficiently (short of allocating a `BOOL *`, but that's overkill). — Itai Ferber, Oct 18 '16 at 15:10
@TejaNandamuri: What if the caller passes NULL for NSError parameter. — saikamesh, Oct 18 '16 at 15:16
@saikamesh: That would be a programming error if there is ever an error while trying to get the BOOL value. So if getting the BOOL fails, you assert that error != NULL and store an error value. It will crash, the programmer in question will fix it. — gnasher729, Oct 19 '16 at 10:07
An alternative is passing a default value that will be returned if getting the BOOL value fails. — gnasher729, Oct 19 '16 at 10:08
I think the second option (bool + error) is a good idea, standard and accepted procedure, and it is compatible with Swift as well, altogether, I would go for that, but of course, you need to document your method's function for your framework clearly, which explain exactly to the framework's users, when the return value is `NO`, the error may be populated by further information about the failure, and if the return value is `YES`, the error is always `nil` ; and it may be good to keep such policy through the entire framework for the consistent behaviour. — holex, Oct 26 '16 at 11:16
I agree with @ItaiFerber. What about using NSNumber instead of BOOL? You would be able to return true, false or nil. I know your original idea was returning a BOOL value, but that solves your problem simply changing the variable type. — VitorMM, Oct 27 '16 at 11:44

Rob Napier · Accepted Answer · 2016-10-26T13:42:38.270

The API for this is long-established by NSUserDefaults, and should be your starting point for designing your API:

- (BOOL)boolForKey:(NSString *)defaultName;

If a boolean value is associated with defaultName in the user defaults, that value is returned. Otherwise, NO is returned.

You should avoid creating a different API for fetching bools from a keystore unless you have a strong reason. In most ObjC interfaces, fetching a non-exixtant key returns nil and nil is interpreted as NO in a boolean context.

Traditionally, if one wants to distinguish between NO and nil, then call objectForKey to retrieve the NSNumber and check for nil. Again, this is behavior for many Cocoa key stores and shouldn't be changed lightly.

However, it is possible that there is a strong reason to violate this expected pattern (in which case you should definitely note it carefully in the docs, because it is surprising). In that case, there are several well established patterns.

First, you can consider fetching an unknown key to be a programming error and you should throw an exception with the expectation that the program will soon crash because of this. It is very unusual (and unexpected) to create new kinds of exceptions for this. You should raise NSInvalidArgumentException which exists exactly for this problem.

Second, you can distinguish between nil and NO by correctly using a get method. Your method begins with get, but it shouldn't. get means "returns by reference" in Cocoa, and you can use it that way. Something like this:

- (BOOL)getBool:(BOOL *)value forKey:(NSString *)key {
    id result = self.values[key];
    if (result) {
        if (value) {
            // NOTE: This throws an exception if result exists, but does not respond to 
            // boolValue. That's intentional, but you could also check for that and return 
            // NO in that case instead.
            *value = [result boolValue]; 
        }
        return YES;
    }

    return NO;
}

This takes a pointer to a bool and fills it in if the value is available, and returns YES. If the value is not available, then it returns NO.

There is no reason to involve NSError. That adds complexity without providing any value here. Even if you are considering Swift bridging, I wouldn't use NSError here to get throws. Instead, you should write a simple Swift wrapper around this method that returns Bool?. That's a much more powerful approach and simpler to use on the Swift side.

I have chosen to implement and document the method as it is done in NSUserDefaults. — saikamesh, Nov 02 '16 at 07:53

score 3 · Answer 2 · edited May 23 '17 at 10:32

If you wish to communicate passing a non-existent key as a programmer error, i.e. something that should actually never occur during runtime because for instance something upstream should have taken care of that possibility, then an assertion failure or NSException is the way to do it. Quoting Apple's documentation from the Exception Programming Guide:

You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime.

If you wish to communicate a runtime error from which the program can recover / can continue executing, then adding an error pointer is the way to do it.

In principle it is fine to use BOOL as the return type there even if there is a non-critical error case. There are however corner cases with this in case you intend to interface with this code from Swift:

If you are accessing this API via Swift, NO always implies that an error is thrown, even if in your Objective-C method implementation you do did not populate the error pointer, i.e. you would need a do / catch and handle specifically of a nil error.
The opposite actually is also valid, i.e. it is possible to throw an error in the success case (NSXMLDocument for instance does this to communicate non-critical validation errors). There is to my knowledge no way to communicate this non-critical error information to Swift.

If you do intend to use this API from Swift, I would perhaps box the BOOL to a nullable NSNumber (at which case the error case would be nil, and the successful NO case would be an NSNumber with NO wrapped in it).

I should note, for the specific case of a potentially failable setter, there are strong conventions that you should follow, as noted in one of the other answers.

score 1 · Answer 3 · answered Nov 01 '16 at 10:12

You pinpoint the major weakness in Apples error handling approach.

We are dealing with those situations by guaranteeing that the NSError is nil in success cases, so you actually check the error:

if (error) { 
    // ... problem
    // handle error and/ or return        
}

As this contradicts Apples error handle, where an Error is never guaranteed to be nil, but is guaranteed to be not nil in failure cases, affected methods have to be well documented to the clients know about this special behaviour.

This is not a nice solution, but the best I know.

(This is one of the nasty things we do not have to deal with any more in swift)

score 0 · Answer 4 · answered Oct 26 '16 at 13:42

If You want all these

Distinguish between failure and success cases
Work with the bool value only if it is a success
In case of failure, caller mistakenly does not think return value is the value of the key

I suggest to make a block based implementation. You'll have a successBlock and errorBlock to clearly separate.

Caller will call the method like this

[self getBoolValueForKey:@"key" withSuccessBlock:^(BOOL value) {
    [self workWithKeyValue:value];
} andFailureBlock:^(NSError *error) {
    NSLog(@"error: %@", error.localizedFailureReason);
}];

and the implementation:

- (void)getBoolValueForKey:(NSString *)key withSuccessBlock:(void (^)(BOOL value))success andFailureBlock:(void (^)(NSError *error))failure {

    BOOL errorOccurred = ...

    if (errorOccurred) {
        // userInfo will change
        // if there are multiple failure conditions to distinguish between
        NSDictionary *userInfo = @{
                               NSLocalizedDescriptionKey: NSLocalizedString(@"Operation was unsuccessful.", nil),
                               NSLocalizedFailureReasonErrorKey: NSLocalizedString(@"The operation timed out.", nil),
                               NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString(@"Have you tried turning it off and on again?", nil)
                               };

        NSError *error = [NSError errorWithDomain:@"domain" code:999 userInfo:userInfo];
        failure(error);

        return;
    }

    BOOL boolValue = ...
    success(boolValue);
}

iCyberPaul · Answer 5 · 2016-10-27T10:14:03.613

We use this

- (id) safeObjectForKey:(NSString*)key {
    id retVal = nil;

    if ([self objectForKey:key] != nil) {
        retVal = [self objectForKey:key];
    } else {
        ALog(@"*** Missing key exception prevented by safeObjectForKey");
    }

    return retVal;
}

Header file NSDictionary+OurExtensions.h

#import <Foundation/Foundation.h>
@interface NSDictionary (OurExtensions)
- (id) safeObjectForKey:(NSString*)key;
@end

score 0 · Answer 6 · answered Oct 28 '16 at 05:37

In this case, I would prefer returning NSInteger with returning 0, 1 and NSNotFound if caller passes key that doesn't exist. From the nature of this method, It should be caller judgement to handle NSNorFound. As I can see, returning error is not very encouraging to user from the method's name.

Error/Exception handling in a method that returns bool

6 Answers6