CoreData error

[Owen Hartnett]

Here's a piece of code I use a lot, particularly when I'm wrestling with UI annoyances that I can't seem to get quite straight:

// useful debugging method - send it a view and it will log all subviews
// can be called from the debugger
- (void) viewAllSubviews:(UIView *) topView Indent:(NSString *) indent  {
	for (UIView * theView in [topView subviews]){
		NSLog(@"%@%@", indent, theView);
		if ([theView subviews] != nil)
			[self viewAllSubviews:theView Indent: [NSString stringWithFormat:@"%@ ",indent]];
	}
}

I throw this in my AppDelegate so I can call it from anywhere.  For the first parameter, just give it a parent view, and it will dump out indented all the subviews.  Usage is (from the debugger):

po [appDelegate viewAllSubviews:rootViewController.view Indent:@"  "];



You can replace any parent view for rootViewController.view, and use whatever number of spaces you want to indent.  

I breakpoint and clear the console, and call it from the debugger, select all then copy and paste into a BBEdit window (or any text window).  It displays a nice tree of my subviews and displays which frames are where, etc., better than stepping through them all.

Another good tip, is that when the impossible is happening, your assumptions are wrong.  The other day one of my colleagues spent a day on a nasty bug where he was moving a view around in response to a gesture.  He saw the frame coordinates change in the debugger, but the view stayed in the same spot!  Turns out he was changing the coordinates in a thread, and it needed to be done on the main thread (because it was graphics-related), but it's a good example of where the impossible (a view visibly in one place, but it's frame coordinates indicating another) is happening.

-Owen

On Jun 18, 2014, at 12:24 PM, John Shockey <john at johncshockey.com> wrote:

> Owen,
> 
> Thanks.
> 
> I don't know how many folks are on this list. I don't think the ones
> I've heard from today need this, but here's a list of debugging tips.
> 
> If it's an easy bug, just do whatever works. But if you're stuck,
> consider:
> 
> 1. The most important debugging tool is your brain.
> 
> 2. Look hard at all the information you gather. Don't worry so much
> about immediately finding the bug. Just look for anything that isn't
> what you expected. Try to understand it, and you may find the bug shows
> itself in the process. (That was the solution for today's bug.)
> 
> 3. Try single stepping through your code. I often do this with new code,
> especially if it's at all complicated, even if no bugs have shown up.
> While stepping, follow rules 1 and 2.
> 
> 4. If an API call doesn't behave the way you expect, don't be too quick
> to decide it's a bug in the API. Think as if you were implementing that
> API -- what information would you have available, and how could you make
> it work?
> 
> 5. Multi-threading issues have their own rules. Treat them like a math
> problem and try to prove you code correct. Alternatively, treat it as a
> puzzle and look for an exception. This is more theoretical than most
> debugging. Multi-threading issues are difficult!
> 
> 6. If a bug is really hard to reproduce (see especially #5), don't give
> up easily when it finally occurs. I've been known to leave my debugger
> stopped on a bug for a day. It's slow, but if it takes you days to make
> it happen it's often worth it.
> 
> 
> Anyone else have any favorites?
> 
> John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mactechgroup.org/pipermail/mactechgroup-discuss/attachments/20140618/a5b1a524/attachment.html>