|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
I'm incorporating NSError into a framework, and I've got a question about method naming conventions: How do you name a method that passes out an NSError object by indirection, but that has no other parameters? To make my question concrete, I have an instance method, -[PFUIElement applicationElement], which returns an object or, if an error occurs, nil. I don't want to name it -applicationElementError:, because that reads as if the return value will be an NSError object. I thought of -applicationElementOrError:, or -applicationElementOrReturnError:, both of which are accurate but feel a little awkward. There are examples from older technologies that I could follow, such as -[NSAppleScript executeAndReturnError:], but, like I say, those are using older technologies for the error: parameter and so the analogy isn't exact. Furthermore, the 'And' part feels inaccurate because they don't return an error if none occurred. Also, all of them that I've noticed are verbs and perform actions, rather than nouns named after the object they return as a direct result. (Methods that take the error parameter as a direct incoming object, such as several methods that present errors, aren't good analogies.) I could always return the error via a delegate method, on the model of -[NSXMLDocument validateAndReturnError:], instead of returning it by indirection. But the use of a delegate method should, I think, be reserved for those special situations where using a parameter for indirection isn't possible (for example, when you're using KVC and the method names are dictated by values returned from some other API over which you have no control). Absent convincing arguments to the contrary, I guess I will settle on -applicationElementAndReturnError:, because of the existing examples using older technologies and the NSXMLDocument delegate method. I can live with 'And' on the theory that there are in fact two routes that can return values, even though one of the return values will always be nil or NULL. -- Bill Cheeseman - email@hidden Quechee Software, Quechee, Vermont, USA http://www.quecheesoftware.com PreFab Software - http://www.prefab.com/scripting.html The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes _______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.