Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
- Subject: Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
- From: Mikkel Islay <email@hidden>
- Date: Thu, 30 Aug 2012 13:49:54 +0200
Hi Alex,
On 30 Aug 2012, at 05:03, Alex Zavatone 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?
The crux of the matter, I think, is that there exist an experience-gap between the people who develop Xcode and a certain proportion of its users.
Taking your compliant as an example: symbolic breakpoints, and the concept of setting them on exceptions in a debugger is not a Cocoa or Xcode-specific technique. For developers with a background in programming-languages and APIs where exception-handling is an integrated pattern, it will seem a natural thing to do. I imagine the Xcode-developer team has that background. However for developers with different backgrounds, e.g. with primary development-experience from UIKit/AppKit, it will be less obvious, because exception-handling patterns are much less used in code based on those frameworks.
In general, Xcode is used by developers in a continuum of experience-levels. With respect to Xcode-development, a tension exist between advancing the state of the tools, and shoring up the users to use them effectively. I don't think what you suggest can be achieved effeiciently from within Xcode. It is much better addressed with training and improved documentation. Jens Afke mentioned better and more broad documentation of Xcode itself.To that I would add documentation that improves understanding of how the frameworks work, focused on the internals rather than the interfaces themselves. To some extent, it is also a community effort. Sites like Stack-overflow, exist for that purpose.
Having written that, I think your concerns are fair. Xcode is, in practice, the only tool variable for developing for Apple's platforms, and it should take the needs and wants of its users seriously. In general, I think it is. Consider how UIKit and certain core-concepts, are described several tiers of documentation, aimed at developers at different levels of expertise.
Mikkel
_______________________________________________
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