Re: NSError naming convention?
Re: NSError naming convention?
- Subject: Re: NSError naming convention?
- From: Ali Ozer <email@hidden>
- Date: Tue, 30 May 2006 14:09:03 -0700
We don't have a convention for exactly that, since, as you discovered,
there's no real precedent. applicationElementAndReturnError: sounds a
bit strange. One option might be to go with a "get" method that
returns two values:
- (BOOL)getApplicationElement:(id *)elementPtr error:(NSError **)
errorPtr
another is to omit reference to the error altogether (this violates a
few rules, but it's not that bad).
- (id)applicationElement:(NSError *)errorPtr;
I agree with you that going with a delegate method here doesn't seem
necessary.
Another question to be asked is whether you need an NSError return
here. We typically recommend using NSErrors on methods which have
multiple failure modes and whose failure is interesting to report to
the user. This is typically not the case for accessors (which explains
the lack of precedents in this area), but on the other hand, there are
many methods named like accessors which do more than just accessing;
so I can see the need eventually coming up.
Ali
On May 29, 2006, at 4:17 AM, Bill Cheeseman wrote:
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
_______________________________________________
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