Re: NSError: why returned directly?
Re: NSError: why returned directly?
- Subject: Re: NSError: why returned directly?
- From: "Keith Ray" <email@hidden>
- Date: Wed, 26 Apr 2006 10:22:20 -0700
In some of my own code, I'm following a convention borrowed from
Python, which allows a method to return a "tuple" (a sort of
non-mutable array). Python's syntax also allows a concise multiple
assignment of the contents of the tuple.
aTuple = someObj.someMethod( arg, arg2 );
result = aTuple[0];
errorReturned = aTuple[1];
# or ...
result, errorReturned = someObj.someMethod( arg, arg2 );
Of course, it's much more verbose in objective c, but I put up with that:
NSArray* returnVals = [ someObj.someMethod: arg otherArg: arg2 ];
SomeType* result = [ returnVals objectAtIndex: 0 ];
NSError* errorReturned = [ returnVals.objectAtIndex: 1 ];
Of course, this is subject to consideration of the types involved ( I
don't really want to "box" up non-object types just to stick them into
an NSArray ), performance required, and so on.
On 4/25/06, Scott Anguish <email@hidden> wrote:
>
> On Apr 25, 2006, at 7:49 PM, Ondra Cada wrote:
>
> > does anyone happen to know what is the rationale behind the
> > particular way NSError is returned? It is well possible I am
> > overlooking something pretty obvious, but it seems to me that in a
> > sense, we are returning to the old bad days of error codes returned
> > and explicitly tested anywhere, making the code unnecessarily
> > complex and error-prone.
>
>
> (I'm sure Ali will pipe up if he has the time.. but)
>
> The way that NSErrors are typically returned is by-reference
> parameters .
>
> if a method returns nil instead of an object, and provides an error
> parameter, the error will provide more information. You can tell
> that it failed because it is nil. the error will tell you WHY it
> failed. this is info you can use to present more feedback.
>
> similarly, if a method returns a BOOL YES for success, when it
> returns NO, an NSError can provide more info. if you're code fails,
> you can return NO, and pass the reason WHY the failure occurred up
> the chain.
>
> Error Handling Programming Guide - <http://developer.apple.com/
> documentation/Cocoa/Conceptual/ErrorHandlingCocoa/index.html#//
> apple_ref/doc/uid/TP40001806>
> _______________________________________________
> 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
>
--
C. Keith Ray
<http://homepage.mac.com/keithray/blog/index.html>
<http://homepage.mac.com/keithray/xpminifaq.html>
<http://homepage.mac.com/keithray/resume2.html>
_______________________________________________
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