Cocoa NSError conventions

[0xced]

Follow Cocoa conventions for methods without parameters returning errors, i.e. xxxAndReturnError:(NSError *)error instead of just xxx:(NSError *)error

[blakewatters]

Where have you seen this convention in use within Apple frameworks? All the examples I can think of (ie `NSManagedObjectContext` save:) just pass the error parameter.

…

On Tuesday, August 27, 2013, Cédric Luthi wrote: Follow Cocoa conventions for methods without parameters returning errors, i.e. xxxAndReturnError:(NSError *)error instead of just xxx:(NSError *)error ------------------------------ You can merge this Pull Request by running git pull https://github.com/0xced/AFNetworking AndReturnError Or view, comment on, or merge it at: #1260 Commit Summary - Follow Cocoa conventions for methods without parameters returning errors File Changes - *M* AFNetworking/AFEventSource.h<https://github.com/AFNetworking/AFNetworking/pull/1260/files#diff-0>(4) - *M* AFNetworking/AFEventSource.m<https://github.com/AFNetworking/AFNetworking/pull/1260/files#diff-1>(6) - *M* AFNetworking/AFHTTPClient+Rocket.m<https://github.com/AFNetworking/AFNetworking/pull/1260/files#diff-2>(2) Patch Links: - https://github.com/AFNetworking/AFNetworking/pull/1260.patch - https://github.com/AFNetworking/AFNetworking/pull/1260.diff

-- To stay sane & productive, I don't live in e-mail. If you need to reach me quickly, try this link: https://awayfind.com/blakewatters

[0xced]

Here is an exhaustive list (I think) of methods with and without AndReturnError:

With AndReturnError: (OS X only)

• ABAddressBook saveAndReturnError: (10.5)
• NSAppleScript compileAndReturnError: (10.2)
• NSAppleScript executeAndReturnError: (10.2)
• NSDocument checkAutosavingSafetyAndReturnError: (10.7)
• NSDocument duplicateAndReturnError: (10.7)
• NSEditor (protocol) commitEditingAndReturnError: (10.7)
• NSXMLDocument validateAndReturnError: (10.4)
• ODNode subnodeNamesAndReturnError: (10.6)
• ODNode supportedRecordTypesAndReturnError: (10.6)
• ODNode unreachableSubnodeNamesAndReturnError: (10.6)
• ODRecord deleteRecordAndReturnError: (10.6)
• ODRecord passwordPolicyAndReturnError: (10.6)
• ODRecord synchronizeAndReturnError: (10.6)
• ODSession nodeNamesAndReturnError: (10.6)
• PDEPanel (protocol) restoreValuesAndReturnError: (10.4)
• PDEPanel (protocol) saveValuesAndReturnError: (10.4)

With AndReturnError: (both iOS and OS X)

• NSBundle loadAndReturnError: (10.5 / 2.0)
• NSBundle preflightAndReturnError: (10.5 / 2.0)
• NSFileVersion removeAndReturnError: (10.7 / 5.0)
• NSURL checkResourceIsReachableAndReturnError: (10.6 / 5.0)

Without AndReturnError: (both iOS and OS X)

• AVCaptureDevice lockForConfiguration: (10.7 / 4.0)
• EKEventStore commit: (10.8 / 5.0)
• NSAtomicStore load: (10.5 / 3.0)
• NSAtomicStore save: (10.5 / 3.0)
• NSFetchedResultsController performFetch: (3.0)
• NSIncrementalStore loadMetadata: (10.7 / 5.0)
• NSManagedObject validateForDelete: (10.4 / 3.0)
• NSManagedObject validateForInsert: (10.4 / 3.0)
• NSManagedObject validateForUpdate: (10.4 / 3.0)
• NSManagedObjectContext save: (10.4 / 3.0)
• NSPersistentStore loadMetadata: (10.6 / 3.0)

So overall CoreData seems to be the exception rather than the rule. But yay for Cocoa consistency. 😖

[blakewatters]

Meh. I find the AndReturnError to be in unappealing and noisy. I wonder what the relative ages of these API's are -- i.e. is this a legacy convention (I am on cell so can't easily check myself ATM)

…

On Tuesday, August 27, 2013, Cédric Luthi wrote: Here is an exhaustive list (I think) of methods with and without * AndReturnError:* With *AndReturnError:* (OS X only) - ABAddressBook saveAndReturnError: - NSAppleScript compileAndReturnError: - NSAppleScript executeAndReturnError: - NSDocument checkAutosavingSafetyAndReturnError: - NSDocument duplicateAndReturnError: - NSEditor (protocol) commitEditingAndReturnError: - NSXMLDocument validateAndReturnError: - ODNode subnodeNamesAndReturnError: - ODNode supportedRecordTypesAndReturnError: - ODNode unreachableSubnodeNamesAndReturnError: - ODRecord deleteRecordAndReturnError: - ODRecord passwordPolicyAndReturnError: - ODRecord synchronizeAndReturnError: - ODSession nodeNamesAndReturnError: - PDEPanel (protocol) restoreValuesAndReturnError: - PDEPanel (protocol) saveValuesAndReturnError: With *AndReturnError:* (both iOS and OS X) - NSBundle loadAndReturnError: - NSBundle preflightAndReturnError: - NSFileVersion removeAndReturnError: - NSURL checkResourceIsReachableAndReturnError: Without *AndReturnError:* (both iOS and OS X) - AVCaptureDevice lockForConfiguration: - EKEventStore commit: - NSAtomicStore load: - NSAtomicStore save: - NSFetchedResultsController performFetch: - NSIncrementalStore loadMetadata: - NSManagedObject validateForDelete: - NSManagedObject validateForInsert: - NSManagedObject validateForUpdate: - NSManagedObjectContext save: - NSPersistentStore loadMetadata: So overall CoreData seems to be the exception rather than the rule. But yay for Cocoa consistency. [image: 😖] — Reply to this email directly or view it on GitHub<#1260 (comment)> .

-- To stay sane & productive, I don't live in e-mail. If you need to reach me quickly, try this link: https://awayfind.com/blakewatters

[0xced]

I updated the list with availability information and it turns out this is not much a legacy vs modern way to write APIs, it’s just different teams being inconsistent.

[blakewatters]

Okay well if there's no clear standard then -1

…

On Tuesday, August 27, 2013, Cédric Luthi wrote: I updated the list with availability information and it turns out this is not much a legacy vs modern way to write APIs, it’s just different teams being inconsistent. — Reply to this email directly or view it on GitHub<#1260 (comment)> .

-- To stay sane & productive, I don't live in e-mail. If you need to reach me quickly, try this link: https://awayfind.com/blakewatters

[mattt]

Honestly, I've never run into AndReturnError: in the wild myself (as it seems to have fallen out of fashion with iOS). Between general API inertia and no particularly compelling reason to switch to this new convention, I'm alright with just leaving things as they are.

Thanks for pointing this out, though. Interesting stuff.

[rnystrom]

Interesting, I've never seen AndReturnError: before either. I personally agree with @blakewatters in its just extra fuss. I don't understand the appeal for consistency when your example clearly proves that there isn't any consistency.

[0xced]

I wasn’t aware of all these methods when I opened the pull request. I did the research after @blakewatters gave the NSManagedObjectContext save: example. I was familiar with NSBundle loadAndReturnError:, NSXMLDocument validateAndReturnError: and NSURL checkResourceIsReachableAndReturnError: so I assumed it was the convention. Turns out it’s not.

[tewha]

withError: is more common than andReturnError:, and I think was Apple's suggestion at one point. Not going to try to pull an exhaustive list like you did, but across the OS X Frameworks I had 67 hits.

[tewha]

This document is the closest I could find to an authoritative answer: Error Handling

The relevant text there says:

Some Cocoa and Cocoa Touch API pass back errors by reference. As an example, you might decide to store the data that you receive from a web service by writing it to disk, using the NSData method writeToURL:options:error:. The last parameter to this method is a reference to an NSError pointer:

Which is, I think, the closest you'll get to "we don't really care." As long as AFNetworking is being consistent about this, I say good enough. :) Though I admit, I do like the selector specifying the type.

[0xced]

I think we are not talking about the same thing here. There is no xxxWithError: method that takes a NSError ** ( double pointer ) argument. There are a lot of didFailWithError:(NSError *)error delegate methods but that’s a different thing.

[tewha]

Ah, you're right. Missed that about the frameworks. So I guess I've been doing the wrong thing in my code for years now. :)