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.

Attachment: 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

Reply via email to