On Aug 29, 2012, at 8:03 PM, Alex Zavatone <z...@mac.com> wrote: > And if you don't know that Symbolic Breakpoints even exist, or what they are > used for, how do you know that part of the documentation is where to turn to > to find a solution? > If the issue is "I have no idea how to track down what crashed where with > these SIGABRTs", then well, why would I know to turn to the Breakpoint > Navigator to solve my problem?
I understand that it's frustrating. But I don't think that a modern IDE is a simple enough app that you can just explore it from scratch and expect to figure everything out by inspection. So it's not fair to expect that you should be able to hit a crash and be given instructions that tell you exactly how to deal with it (especially given that a crash is, by definition, something unexpected happening in the code.) Although Xcode could do better — see below. There needs to be an Xcode manual. (But nothing really comes with a manual anymore, so at least there are 3rd party books covering Xcode in a fair amount of detail.) Still, the "Xcode User Guide" is the closest thing there is, rudimentary though it is, and I was just pointing out that it _does_ happen to document this feature. I'm not saying it should have been obvious how to find that page when you hit the crash, rather than one hopes you've gone through the user guide before spending too long in Xcode. > I find the need to use the terms "thick" and "obtuse" to describe how Xcode > responds to a SIGABRT and here's why. So, the thing is that there's more going on than SIGABRT. There's a warning being logged to the console by the framework, there's an exception being raised by the framework, there's the exception being caught by the top-level exception handler on the thread, and there's that handler calling abort(). The only one of those Xcode is directly reacting to is the abort() call. I do believe that Xcode projects should default to having a breakpoint set on exception raises, because it's so damn useful. Every project I work on gets one of those set very quickly. I can't think of a good reason not to have this on by default, especially since these days Apple seems determined to make exceptions crash our apps (instead of having them be caught in the event loop.) Believe it or not, this does keep getting better, slowly. Before Xcode 4 there wasn't a handy menu command to set a breakpoint on exceptions; you had to know to type "-[NSException raise]" into the symbolic breakpoint editor. And I seem to recall that early versions of Xcode didn't have a UI for symbolic breakpoints at all, so you had to type the gdb "break" command. (Uphill, in the snow.) > IMO, it's things like having to learn this and having to learn (before 4.4.1) > that you actually had to write your own class descriptors to see the class's > own ivars within a instance in the debugger For what it's worth, you are the only person whom I've ever heard of having that particular problem. I still don't understand what was going on for you that the variable inspector pane didn't work. That sounds more like some weird edge case you ran into than a design issue in Xcode. —Jens PS: And this is totally an xcode-users post, not cocoa-dev, so further posts should probably go there.
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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
