Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
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 (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
Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
On 29 Aug 2012, at 11:51 PM, Jens Alfke j...@mooseyard.com wrote: There needs to be an Xcode manual. A'h'm. (And if anyone has criticisms, I'd be glad to know; I'm working on an ebook supplement.) By the way… PS: And this is totally an xcode-users post, not cocoa-dev, so further posts should probably go there. I haven't seen anything on xcode-users for a couple of days. Mail sent to postmas...@lists.apple.com, assuming that that server does not comply with the RFC requiring postmaster addresses to be ignored. — F -- Fritz Anderson -- Xcode 4 Unleashed -- http://x4u.manoverboard.org/ ___ 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
Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
Wow. Awesome. There should be a web page filled with these somewhere. On Aug 24, 2012, at 9:28 AM, Alex Zavatone z...@mac.com wrote: This is very eye opening and likely to be hugely time saving, especially with those storyboard crashes where you're not in code. http://www.fruitstandsoftware.com/blog/2012/08/quick-and-easy-debugging-of-unrecognized-selector-sent-to-instance/ The graphic in the link might not match up with what's in your version of Xcode, so here's a link that shows how to set them: http://developer.apple.com/library/mac/#recipes/xcode_help-breakpoint_navigator/articles/adding_a_symbolic_breakpoint.html Cheers, - Alex Zavatone ___ 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/mike%40instantvoodoomagic.com This email sent to m...@instantvoodoomagic.com ___ 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
Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
I think you hit the nail on the head, Mike. Things you wish you knew about Xcode or Xcode tips that you wish Apple shipped with the product. Sort of like the links below, but for how to solve common problems that Xcode users normally face. http://secrets.blacktree.com/ https://twitter.com/XcodeTips Xcode tips dot com? Something like that. Maybe there's a domain like that still unregistered. On Aug 29, 2012, at 1:56 PM, Mike Manzano wrote: Wow. Awesome. There should be a web page filled with these somewhere. On Aug 24, 2012, at 9:28 AM, Alex Zavatone z...@mac.com wrote: This is very eye opening and likely to be hugely time saving, especially with those storyboard crashes where you're not in code. http://www.fruitstandsoftware.com/blog/2012/08/quick-and-easy-debugging-of-unrecognized-selector-sent-to-instance/ The graphic in the link might not match up with what's in your version of Xcode, so here's a link that shows how to set them: http://developer.apple.com/library/mac/#recipes/xcode_help-breakpoint_navigator/articles/adding_a_symbolic_breakpoint.html Cheers, - Alex Zavatone ___ 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/mike%40instantvoodoomagic.com This email sent to m...@instantvoodoomagic.com ___ 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
Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
On Aug 29, 2012, at 1:40 PM, Alex Zavatone z...@mac.com wrote: I think you hit the nail on the head, Mike. Things you wish you knew about Xcode or Xcode tips that you wish Apple shipped with the product. It's in the docs — the Breakpoint Navigator Help includes a page on Adding An Exception Breakpoint. If you type exception into the search field in Xcode's Help menu, it's the third hit in the list. —Jens ___ 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
Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
First off, sorry guys, this is long. It's in the docs — the Breakpoint Navigator Help includes a page on Adding An Exception Breakpoint. If you type exception into the search field in Xcode's Help menu, it's the third hit in the list. —Jens But Jens, that's one of the issues. There are quite a lot of docs and multiple ways to get through them. In 26 years on the Mac, I've never found any of Apple's Help menus to be of any use, so I don't expect Xcode's to be. I go straight to command shift 2 and search the docs. There are a lot of docs. 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 find the need to use the terms thick and obtuse to describe how Xcode responds to a SIGABRT and here's why. The Debugger appears with the SIGABRT condition. The Issue Navigator on the left displays all the threads and the calling chain that issued the SIGABRT. There is a nice graphical overlay over the code (which is almost never the code or condition that caused the issue. It's the calling chain of how the SIGABRT is issued, not the calling chain of the problem itself or storyboard object where the issue occurred. If it's a miswired storyboard object, or a name mismatch on a segue, your eye is brought to what the Debugger is showing you and it's pretty much 100% not where your problem is. You're not going to see what you need to help guide you to solve the problem. You can press the back triangle to see if any of your classes directly caused this problem, but rarely do I see the cause displayed to me in the the calling chain or the code that is displayed. Basically, the Debugger and Issues Navigator, which are meant help you, are 100% useless in this case (based on my experience) and also are completely misleading since when the Debugger is displayed, your focus is drawn to it and the information in it because you expect it to help solve the issue that caused it to appear in the first place. However, if you are lucky enough to be paying attention to the tiny console pane, you'll actually get the only message that tells you WHY there is a SIGART, something you expected the Debugger and Issue Navigator to do. unrecognized selector sent to instance We've immediately got a design issue in Xcode in that this issue should be displayed in the area of main focus - the Debugger - not the calling chain of how thread 1just issued that SIGABRT. So, now that we know that something is sending an unrecognized selector to an instance, this tells us that OC's way of operating is to crash when it passes an unimplemented message to an object. (Months back, you corrected me when I claimed that sending a message to a nil instance caused crashes of this nature. Sorry, I had it backwards.) At this point, we are SO FAR AWAY from actually knowing that I should look up Symbolic Debugger Breakpoints in the documentation or in the Breakpoints Navigator Help since that will solve my problem. Sure, it's in the documentation (and in the BP Nav help) but based on: the nature of the crash, what Xcode tells you, what the issue really is and where to go in your code or a storyboard to fix it, it's painfully unclear that: Symbolic Debugger Breakpoints exist at all, Symbolic Breakpoints will help you get to the solution, I could have turned to the BP Nav help to guide me to the solution - breakpoints weren't even in use, so why should someone turn there? Besides the fact that Xcode is not presenting the most useful information in the area where it would do the most good, we are faced with the reverse dictionary lookup problem.The problem of I need a word that fits this definition, I need a solution to allow me to solve this problem and we don't have a good problem resolution look up system (that I am aware of) in Xcode. IF there is another amazing undiscovered feature in Xcode that does a here is my problem, please point me to a solution that I do not know about, then please tell me what it is, but I haven't found it yet. Searching Help has rarely been useful. Previously, when I searched in the search field under the Help menu, all I would ever see is Help that is relevant to the Menu items or is vaguely related to what I searched for and appearing irrelevant to the issue at hand. If you search help the first few times and don't get a solution, you look somewhere else and end up not relying on that service. If I'm missing something here about Help and the docs, please let me know. From my experience with the product here's literally no way to that solution unless you're lucky enough to have stumbled across it unintentionally.
Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
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
Re: On handling those lovely unrecognized selector sent to instance SIGABRTs
On Aug 24, 2012, at 9:28 AM, Alex Zavatone z...@mac.com wrote: This is very eye opening and likely to be hugely time saving, especially with those storyboard crashes where you're not in code. http://www.fruitstandsoftware.com/blog/2012/08/quick-and-easy-debugging-of-unrecognized-selector-sent-to-instance/ It's better to set a breakpoint on exception raises. That way you stop at the point of failure for all sorts of exceptions, not just this particular one. This is an indispensable debugging tool. This is even easier to set up. From that same pop-up choose Add Exception Breakpoint…. Then press Done. That's it. —Jens 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
