• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Fixing logged error that doesn't throw exception
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixing logged error that doesn't throw exception


  • Subject: Re: Fixing logged error that doesn't throw exception
  • From: Quincey Morris <email@hidden>
  • Date: Thu, 25 Jun 2009 11:10:46 -0700

On Jun 25, 2009, at 02:34, Tristan Celder wrote:

I'm extremely new to Cocoa programming but have come across a problem where I am getting a [NSConcreteAttributedString initWithString:] called with nil string argument. pop up in my console. I have had it once before and managed to track it down to a NumberFormatter with no symbols set for nil/null values. This problem was the cause of a far more serious problem which was a very bizarre error which breaks my core data bindings for any table view displaying exactly one row of an attribute fetched via a relationship when a document is reopened after save.

Unfortunately the console warnings have begun popping up again, and this time I have absolutely no idea where/who/what could be causing them in my interface. (It's only when I do a clean build that they show up in the first place). So... what I would really like to know is how I can find the source of these messages. A previous post I dug up, simply mentions that one can "test the location on the stack which holds the parameter." which can be done using the syntax "*(id*)($ebp + 16)".

Now, as I'm new to cocoa development (And C in general), my knowledge of gdb is limited. How would I set this breakpoint from xcode?

When you ask questions about errors logged on the console, you'll get a much more helpful response if you paste the exact text of the message in your post. :)


It sounds like the "console warnings" you're seeing are in fact exceptions -- which are very far from being warnings. When you see an exception logged, your application has pretty much shot itself in the foot, and you can't expect execution to continue correctly.

To stop in the debugger at an exception, set a symbolic breakpoint at (if you're using 10.5) 'objc_exception_throw' -- open the breakpoint window (Command-Option-B, probably), double-click where it says "Double-click for symbol', type in that symbol name and press Return. (Leave that breakpoint in, um, forever.)

Run your application with "Build and Debug" (instead of "Build and Run"), and it'll stop in the debugger when the exception occurs. You can then examine the backtrace in the debugger window to see where in your code the exception occurred, and how you got there.


_______________________________________________

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


References: 
 >Fixing logged error that doesn't throw exception (From: Tristan Celder <email@hidden>)

  • Prev by Date: Recalculating NSTableView row sizes during a live column resize
  • Next by Date: Re: Ideas required on testing an application install
  • Previous by thread: Re: Fixing logged error that doesn't throw exception
  • Next by thread: Re: Fixing logged error that doesn't throw exception
  • Index(es):
    • Date
    • Thread