NSError and user-cancel induced "errors"
NSError and user-cancel induced "errors"
- Subject: NSError and user-cancel induced "errors"
- From: "Timothy J. Wood" <email@hidden>
- Date: Thu, 29 Sep 2005 10:50:54 -0700
The NSError documentation has this to say:
<file:///Developer/ADC Reference Library/documentation/Cocoa/
Conceptual/ErrorHandlingCocoa/index.html#//apple_ref/doc/uid/TP40001806>
"Note: Cocoa methods that indirectly return error objects in the
Cocoa error domain are guaranteed to return such objects if the
method indicates failure by directly returning nil or NO."
This seems to ignore a very important set of cases (which were
previously annoying in NSDocument) in which a user cancels an
operation. Say I have a call tree like:
- NSDocument file loading method
- Subclass file loading method
- Model object loading code
- Delegate hook to ask the user about a upgrading the file,
warning of an inconsistency, etc.
(This is only an example, obviously, there are any number of other
cases where this issue can arise)
Now, if you give the user the option to cancel the operation
entirely you will end up needing to both return NO/nil on your method
to indicate that further processing shouldn't continue AND you'll not
really want to return an error. Certainly you don't want an error
displayed when the user canceled the operation. But, if we need to
match the constraint noted in the documentation (particularly when
subclassing Cocoa objects like NSDocument) we have no defined way to
prevent an error from being displayed.
The most obvious approach is to either define a new error domain
that is the 'user canceled domain' or to define a new user-info key
that indicates that the error is due to the user canceling the
operation. This allows you to check for it in your -
application:willPresentError: method.
Have I missed some bit of documentation that says how Apple
recommends handling this case, or should I log a bug requesting this
be added to NSError?
-tim
_______________________________________________
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