Re: Returning a useful error from NSDocument's -readFromURL:...
Re: Returning a useful error from NSDocument's -readFromURL:...
- Subject: Re: Returning a useful error from NSDocument's -readFromURL:...
- From: Quincey Morris <email@hidden>
- Date: Thu, 4 Mar 2010 01:17:13 -0800
On Mar 3, 2010, at 13:52, Keith Blount wrote:
> Okay, I know this comes up a lot, but I can't find a single page with a satisfactory solution. Please feel free to post nothing but a link with the solution if I have missed the bloomin’ obvious, of course - this question has been asked here before and in other places, and it seems as though it should be simple, but nothing I try is entirely satisfactory:
No, what you're experiencing doesn't come up a lot.
> My app overrides NSDocument's -readFromURL:ofType:error: to load its data. For the different circumstances in which the load might fail, I want to present to the user an alert panel explaining the reason for the failure. This, as I understand it, is the entire purpose of NSError, except that in this circumstance it seems to be doing more harm than good and just doesn't work as it should.
>
> First, let's say I want to say to the user, "Invalid XML Data". And underneath that, in smaller, message text, I want it to say something like, "The document cannot be loaded because the XML file contained invalid characters."
You seriously need to read the human interface guidelines. There is a preferred pattern laid down for reporting errors, and this isn't it.
> So, here is my error-setting:
>
> if (outError)
> {
> NSMutableDictionary *userInfo = [NSMutableDictionary dictionary];
> [userInfo setObject:NSLocalizedString(@"Invalid XML Data", @"") forKey:NSLocalizedDescriptionKey];
> [userInfo setObject:NSLocalizedString(@"The document cannot be loaded because the XML file contained invalid characters.",nil) forKey: NSLocalizedFailureReasonErrorKey];
>
> *outError = [NSError errorWithDomain:@"" code:0 userInfo:userInfo];
> }
>
> That works okay, except that the failure reason doesn’t get displayed.
What precisely does "works okay" mean? Based on what you said above, you seem to be saying that you got an alert saying "Invalid XML Data".
However, that's not the way the standard document controller reports errors. In the simplest case, it just displays a generic message: "The document “whatever” could not be opened." If you supply a failure reason, it appends that as a second sentence. For example, moments ago I created a new project from the standard document-based application template (Xcode 3.2, Mac OS X 10.6.2), changed the "readFromData" method to readFromURL:ofType:error: and used your code to return an error. I got an alert with the following text:
"The document “whatever” could not be opened. The document cannot be loaded because the XML file contained invalid characters."
That doesn't sound like "the failure reason doesn't get displayed".
> [snip] I have tried to set outError as follows:
>
> if (outError)
> *outError = [NSError errorWithDomain:NSCocoaErrorDomain code:NSUserCancelledError userInfo:nil];
>
> But that results in an alert panel coming up saying nothing more than “Alert” - it still displays an error panel.
I haven't seen any indication that the standard document controller fails to handle the NSUserCancelledError correctly (that is, fails to suppress the alert).
It sure looks like there's something in your application that's superseding the normal error reporting, and doing so incorrectly. If there's truly nothing like that in your application, I'd suggest you try to recreate the the behavior you're seeing in a new, simple project that starts with the document-based application template.
> [snip]
>
> What is the correct way of handling this? It’s bad enough that the user has to see an error message at all (although on some occasions it may be used to tell the user that the project needs updating to a newer format, which is more common than genuine errors), without the error messages seeming unprofessional or unforthcoming in the information they provide. Of course, I could put all of the information into NSLocalizedDescriptionKey, but this looks horrible as it’s all in bold, and would then be one stream of text without a title. Really it should have a title telling the user succinctly that there has been an error an then some message text explaining more about the error and possibly what to do about it.
I'm sorry if it looks horrible to you "all in bold". I'm sorry if you feel the need for a "title" -- whatever that means. Seriously (on your way to seriously reading the human interface guidelines), get over it. It's to every Mac user's benefit if all applications report errors with a consistent presentation and style, and that is what the HIG are there to encourage, if not enforce.
I apologize if my response seems churlish, but your original post is basically a ragedump and a rant. Churlish is about what it deserves.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden