Re: Failure on unarchiving a NSBezierPath
On Tue, Apr 29, 2008 at 12:01 AM, Kyle Sluder <[EMAIL PROTECTED]> wrote: > You know what? I don't think you've ever said that you know that > view.drawing != nil. Check that. > > --Kyle Sluder > Oh, what a shame for me to overlook such a critical check! Thank you for helping me find this foolish error. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
On 28 Apr '08, at 8:56 AM, Kyle Sluder wrote: Not necessarily true in the general case. The semantics of buffered output may interfere, especially if instead of just sending unrecognized selectors to a random object the code were sending messages to a pointer off in la-la land. It's always a nightmare to watch students toss printf() everywhere in their C code in an attempt to figure out where the program is crashing and then not see messages they know should be displayed. That can happen with printf, or other calls that write to stdout; but stderr is unbuffered, so output will show up right away (and in correct order.) NSLog writes to stderr, as does all other properly- written logging code. —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
> You know what? I don't think you've ever said that you know that > view.drawing != nil. Check that. Though NSArchiver says this scenario would produce an exception, NSKeyedArchiver does not seem to do the same (the documentation doesn't say what will happen and a quick test with an NSBezierPath shows that it indeed does not). In other words, you will get a valid archive (not nil and not an exception) to save; it's just an empty one. So this suggestion is an important one - you should definitely check to make sure you're not trying to archive nil instead of an NSBezierPath instance. Regarding the other aspect of this post, the point that the OP should fix the NSError bug has been well-made. Let's not turn this thread into a fifty-message-long "I disagree that you disagree !" and "Yeah? well I disagree because you clearly didn't understand !" ... those only ever degenerate into mud-slinging contests worthy of nomination for the 2008 Pedantic Pontificator Awards. ;-) -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
On Wed, Apr 23, 2008 at 11:42 AM, an0 <[EMAIL PROTECTED]> wrote:
> I was building a very simple drawing application, but met problems
> when reading the file saved by my application.
>
> The two functions as to archiving/unarchiving are as follows:
> - (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
> {
>return [NSKeyedArchiver archivedDataWithRootObject:view.drawing];
> }
You know what? I don't think you've ever said that you know that
view.drawing != nil. Check that.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
On Mon, Apr 28, 2008 at 11:45 AM, Michael Ash <[EMAIL PROTECTED]> wrote: > Nothing is being obstructed. The logged errors happen after the > primary problem occurs. If the primary problem were logging errors, > they would appear before the ones that are caused by the lack of an > error assignment. If nothing appears there, then nothing is being > logged. Not necessarily true in the general case. The semantics of buffered output may interfere, especially if instead of just sending unrecognized selectors to a random object the code were sending messages to a pointer off in la-la land. It's always a nightmare to watch students toss printf() everywhere in their C code in an attempt to figure out where the program is crashing and then not see messages they know should be displayed. > It certainly makes sense to fix this problem. An easy bug should > always be fixed when the opportunity arises. But it's not hurting > efforts to fix the larger problem as it stands. I'd tend to disagree slightly with the latter statement; first, it's a distraction, and secondly it could potentially make running the code in gdb or whatnot a problem (how do you break on an error that's thrown when the error itself is non-deterministic?). Again, I'm thinking of the general case, and in this situation there's no reason *not* to fix the known bug first. That's all I'm asking get done so that the number of "safe" debugging options increases. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
On Mon, Apr 28, 2008 at 11:03 AM, Michael Ash <[EMAIL PROTECTED]> wrote: > I don't think you're getting the point yourself. The reason he's > returning NO is because his unarchiving fails, and it shouldn't fail. > Certainly the code *should* set the error (if outError is non-nil) but > this is a secondary problem, as that code path shouldn't even happen. But how useful can the console log be in fixing *this* problem if one is knowingly causing Cocoa to send messages to what amounts to a random pointer? When presented with a glaring and easily-fixable bug that could obstruct fixing another, doesn't it make sense to fix it first rather than continue to attempt to figure out the more complicated bug? --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
On Mon, Apr 28, 2008 at 11:43 AM, Kyle Sluder <[EMAIL PROTECTED]> wrote: > On Mon, Apr 28, 2008 at 11:03 AM, Michael Ash <[EMAIL PROTECTED]> wrote: > > I don't think you're getting the point yourself. The reason he's > > returning NO is because his unarchiving fails, and it shouldn't fail. > > Certainly the code *should* set the error (if outError is non-nil) but > > this is a secondary problem, as that code path shouldn't even happen. > > But how useful can the console log be in fixing *this* problem if one > is knowingly causing Cocoa to send messages to what amounts to a > random pointer? When presented with a glaring and easily-fixable bug > that could obstruct fixing another, doesn't it make sense to fix it > first rather than continue to attempt to figure out the more > complicated bug? Nothing is being obstructed. The logged errors happen after the primary problem occurs. If the primary problem were logging errors, they would appear before the ones that are caused by the lack of an error assignment. If nothing appears there, then nothing is being logged. It certainly makes sense to fix this problem. An easy bug should always be fixed when the opportunity arises. But it's not hurting efforts to fix the larger problem as it stands. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
On Mon, Apr 28, 2008 at 2:24 AM, Kyle Sluder <[EMAIL PROTECTED]> wrote: > On Fri, Apr 25, 2008 at 5:10 AM, an0 <[EMAIL PROTECTED]> wrote: > > Thanks a lot if you or others can give me some more hint. > > You really aren't getting the point. > > You're returning NO from -readFromData:ofType:error. You're not > setting *outError to anything meaningful. Therefore your program is > printing out weird logs. Until you fix this bug your error log is > useless and can't help you debug your application. I don't think you're getting the point yourself. The reason he's returning NO is because his unarchiving fails, and it shouldn't fail. Certainly the code *should* set the error (if outError is non-nil) but this is a secondary problem, as that code path shouldn't even happen. As for the original problem, I suggest testing the code piece by piece. Does the resulting NSData look correct (have non-zero contents, reasonable length for the input), does it work if you immediately unarchive right after archiving, does the data you get in the second method match the data you create in the first? Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
On Fri, Apr 25, 2008 at 5:10 AM, an0 <[EMAIL PROTECTED]> wrote: > Thanks a lot if you or others can give me some more hint. You really aren't getting the point. You're returning NO from -readFromData:ofType:error. You're not setting *outError to anything meaningful. Therefore your program is printing out weird logs. Until you fix this bug your error log is useless and can't help you debug your application. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
Sorry for my careless, I though Jens was talking about the `read' part. However, as I said, the error occurred when reading not when writing. So it was not because > NSKeyedArchiver returned nil but because `[NSKeyedUnarchiver unarchiveObjectWithData:data]' returned nil, and my `readFromData:(NSData *)data ofType:(NSString *)typeName error:(NSError **)outError' returned NO without setting `outError' (thanks Jens let me learn this point). OK. Now I'm just wondering why `[NSKeyedUnarchiver unarchiveObjectWithData:data]' returnes nil, since I've saved the data without any error as I can see. Thanks a lot if you or others can give me some more hint. On Fri, Apr 25, 2008 at 4:29 PM, Kyle Sluder <[EMAIL PROTECTED]> wrote: > On Fri, Apr 25, 2008 at 4:11 AM, an0 <[EMAIL PROTECTED]> wrote: > > Thanks. But it seems you haven't read to the end. As I said in my first > mail: > > > > > Besides, I found the value returned by [NSKeyedUnarchiver > > > unarchiveObjectWithData:data] was nil, but I didn't understand why, > > > since it was normal when I saved the file using [NSKeyedArchiver > > > archivedDataWithRootObject:view.drawing]. > > But you apparently haven't comprehended Jens' message. You're not > setting *outError to anything, so whoever is calling your method is > seeing that you've returned NO and is expecting whatever it passed in > as outError to point to an NSError object. Unfortunately this is not > the case and whatever was in that memory location is receiving bogus > messages -- particularly, -localizedFailureReason, which is an NSError > method. > > In short, you're breaking the contract for messages which take an > NSError**. Set *outError to an NSError object (or nil if you're lazy) > if you're going to return a value that signifies an error. > > --Kyle Sluder > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
On Fri, Apr 25, 2008 at 4:11 AM, an0 <[EMAIL PROTECTED]> wrote: > Thanks. But it seems you haven't read to the end. As I said in my first mail: > > > Besides, I found the value returned by [NSKeyedUnarchiver > > unarchiveObjectWithData:data] was nil, but I didn't understand why, > > since it was normal when I saved the file using [NSKeyedArchiver > > archivedDataWithRootObject:view.drawing]. But you apparently haven't comprehended Jens' message. You're not setting *outError to anything, so whoever is calling your method is seeing that you've returned NO and is expecting whatever it passed in as outError to point to an NSError object. Unfortunately this is not the case and whatever was in that memory location is receiving bogus messages -- particularly, -localizedFailureReason, which is an NSError method. In short, you're breaking the contract for messages which take an NSError**. Set *outError to an NSError object (or nil if you're lazy) if you're going to return a value that signifies an error. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
Thanks. But it seems you haven't read to the end. As I said in my first mail: > Besides, I found the value returned by [NSKeyedUnarchiver > unarchiveObjectWithData:data] was nil, but I didn't understand why, > since it was normal when I saved the file using [NSKeyedArchiver > archivedDataWithRootObject:view.drawing]. On Fri, Apr 25, 2008 at 3:20 AM, Jens Alfke <[EMAIL PROTECTED]> wrote: > I suspect what happened is that NSKeyedArchiver returned nil for some > reason, and the caller of that method then looked at *outError to find the > reason for the error; but you didn't store anything in there, so it got > whatever happened to be in that variable, which in this case may have been a > pointer to the NSDocumentController. > > So try adding a test for nil to your save method. It looks like that's > where the problem is. > > —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Failure on unarchiving a NSBezierPath
On 23 Apr '08, at 8:42 AM, an0 wrote:
Nothing appeared when I opened a saved file, and log said:
2008-04-23 23:33:44.127 EasyDraw[631:10b] *** -[NSDocumentController
localizedFailureReason]: unrecognized selector sent to instance
0x11b210
Something sent -localizedFailureReason: to an instance of
NSDocumentController, apparently thinking it was an NSError*.
Given this method:
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
return [NSKeyedArchiver archivedDataWithRootObject:view.drawing];
}
I suspect what happened is that NSKeyedArchiver returned nil for some
reason, and the caller of that method then looked at *outError to find
the reason for the error; but you didn't store anything in there, so
it got whatever happened to be in that variable, which in this case
may have been a pointer to the NSDocumentController.
So try adding a test for nil to your save method. It looks like that's
where the problem is.
—Jens
smime.p7s
Description: S/MIME cryptographic signature
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Failure on unarchiving a NSBezierPath
I was building a very simple drawing application, but met problems
when reading the file saved by my application.
The two functions as to archiving/unarchiving are as follows:
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
return [NSKeyedArchiver archivedDataWithRootObject:view.drawing];
}
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName
error:(NSError **)outError
{
NSBezierPath *drawing = [NSKeyedUnarchiver
unarchiveObjectWithData:data]; //*** returns nil
if (drawing == nil) {
return NO;
} else {
view.drawing = drawing;
return YES;
}
}
Nothing appeared when I opened a saved file, and log said:
2008-04-23 23:33:44.127 EasyDraw[631:10b] *** -[NSDocumentController
localizedFailureReason]: unrecognized selector sent to instance
0x11b210
2008-04-23 23:33:44.128 EasyDraw[631:10b] *** -[NSDocumentController
localizedFailureReason]: unrecognized selector sent to instance
0x11b210
I don't know what the log means.
Besides, I found the value returned by [NSKeyedUnarchiver
unarchiveObjectWithData:data] was nil, but I didn't understand why,
since it was normal when I saved the file using [NSKeyedArchiver
archivedDataWithRootObject:view.drawing].
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
