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: Alex Zavatone <email@hidden>
- Date: Wed, 29 Aug 2012 23:03:27 -0400
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.
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, are among the two (oh yeah, provisioning), make that three, areas where our team has wasted massive amounts of time that could have been spent implementing.
I guess the message from my side of the fence is "why isn't Xcode shipping with a list of top problems and solutions for developers doing iOS, and Developers doing Mac OS"? When you launch the app, for the first time, would presenting the user with an option of "Would you like to see our index of common problems and solutions? Y/N", "Based on how and what you are developing, here are the top issues and solutions that you may wish to be aware of" be a good idea? Or even have a menu under Help for "Common Problems and Resolutions"?
Searching the docs always brings up something, but no one on our team had any idea that either Symbolic Breakpoints were a fast method to get to the root of the problem and that you had to actually write your own description methods to get the debugger and/or the console to be able to display the things we expected it to display.
I think that's about 8 months of wondering why we have to hand enter NSLogs to get variable value output, assuming that people just suffered through SIGABRTs like the rest of us, searching for solutions, searching the docs and the internet for answers to the issues. In other words, massive amounts of hours of nonproductivity.
There's only so much time in the day to allocate to getting and watching WWDC videos and trying to make it through what appear to be the most relevant parts of the documentation
If Xcode did ship with a "pick what you are developing for, I'll give you the top problems and solutions so you are prepared to handle them before you hit them" style issue/solution assistant, there would be many more developers who aren't in the office at 11:00 at night and weekends.
Cheers. Back to crashing the storyboard when I hit undo.
On Aug 29, 2012, at 5:02 PM, Jens Alfke wrote:
>
> On Aug 29, 2012, at 1:40 PM, Alex Zavatone <email@hidden> 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."
_______________________________________________
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