Re: NSError and user-cancel induced "errors"
Re: NSError and user-cancel induced "errors"
- Subject: Re: NSError and user-cancel induced "errors"
- From: Ali Ozer <email@hidden>
- Date: Thu, 29 Sep 2005 14:55:52 -0700
Tim,
There is NSUserCancelledError which is for this purpose. It's
specially treated by the NSError handling machinery in NSDocument/
NSApplication not to put up a panel.
Ali
Begin forwarded message:
From: "Timothy J. Wood" <email@hidden>
Date: September 29, 2005 10:50:54 PDT
To: Cocoa List <email@hidden>
Subject: NSError and user-cancel induced "errors"
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