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 <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."
_______________________________________________
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
