NSError: why returned directly?
NSError: why returned directly?
- Subject: NSError: why returned directly?
- From: Ondra Cada <email@hidden>
- Date: Wed, 26 Apr 2006 01:49:39 +0200
Hello,
if listmom is not offended by a, say, rather academical question...
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.
The trick is, perhaps it is just my fault, or I do something far
wrong, but a *very vast majority* of my usages of NSError tends to
look like this:
-(id)someMethodWithError:(NSError**)error { // pattern X
...
if (![foo anotherMethodWithError:error]) return nil;
...
if (![bar justAnotherMethodWithError:error]) return nil;
...
// and so forth
}
Only a small minority of my methods actually does something with the
error, be it extending, translation of attributes, or whatever. Even
GUI-level often error is just re-directed in the above way, to be
presented the standard way into the responder chain at the top code
level.
Is it just me, or do perhaps others found similar results? I find the
"pattern X" above pretty error-prone and conceptually unclean, and I
feel the more methods in future supports NSError, the more PITA it
will beome. But it might be just my fault or my misunderstanding of
something very basic?
Since the above, I would prefer myself a different, exception-like
implementation. Actually, with the new exception support which can
throw anything, it could have been used directly: instead of setting
NSError into the reference argument and returning a nil (or NO or
whatever), the same NSError would be thrown. Instead of checking for
the return value, NSError would be catched.
Thus, the code--in my personal and possibly faulty opinion--would
become considerably cleaner and less error-prone:
-(id)someMethodWhichGeneratesError:(NSError**)error { // current style
...
if (something) {
if (error) *error=[NSError errorWithDomain:...];
return nil;
}
...
}
would turn to
-(id)someMethodWhichGeneratesError { // proposed style
...
if (something) @throw [NSError errorWithDomain:...];
...
}
Similarly,
-(IBAction)someDocumentMethodWhichUsesError { // current style
...
if (![foo someMethodWhichGeneratesError:error]) {
[self presentError:error modalForWindow:...];
return;
}
...
if (![bar anotherMethodWhichGeneratesError:error]) {
[self presentError:error modalForWindow:...];
return;
}
...
// and so forth
}
would turn to
-(IBAction)someDocumentMethodWhichUsesError { // proposed style
...
@try {
...
[foo someMethodWhichGeneratesError];
...
[bar anotherMethodWhichGeneratesError];
...
// and so forth
} @catch (NSError *error) {
[self presentError:error modalForWindow:...];
}
}
Finally, and best of all, intermediate methods (like my "pattern X"
of above), would not have to check for errors at all, unless they
want to change it. Another advantage would be that there could be a
top-level handler somewhere around the event loop level, which would
harness any action in
@try { ... application code here ... } @catch (NSError *error)
{ [NSApp presentError:error]; }
What am I overlooking, and why something conceptually like this was
not used?
Thanks,
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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