Re: Failure on unarchiving a NSBezierPath
Re: Failure on unarchiving a NSBezierPath
- Subject: Re: Failure on unarchiving a NSBezierPath
- From: "Kyle Sluder" <email@hidden>
- Date: Mon, 28 Apr 2008 11:56:06 -0400
On Mon, Apr 28, 2008 at 11:45 AM, Michael Ash <email@hidden> 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 (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