On Sep 25, 2013, at 12:52 PM, Jerry Krinock wrote:
> After creating such a globally-useful breakpoint, perform a secondary click
> (aka control-click) on it and, in the contextual menu, Move Breakpoint to >
> User.
Holy crap! I never knew that was possible. Thanks a lot!
—Jens
__
On 2013 Sep 25, at 12:39, Alex Zavatone wrote:
> Since this is so useful, is there any way to make each project we create
> automatically gets an exception breakpoint set to All Objective-C Exceptions?
Actually this is veering into xcode-us...@lists.apple.com territory, but I can
answer that.
On Sep 25, 2013, at 1:24 PM, Jens Alfke wrote:
>
> On Sep 25, 2013, at 10:16 AM, Kyle Sluder wrote:
>
>> Please note that the breakpoint traps on exception *throw*. It is perfectly
>> valid—daresay common—for C++ code to throw and catch exceptions as a normal
>> matter of course.
>
> Some o
Thank you, guys.
So the answer is that C++ exceptions are often false alarms.
And the solution is to leave that "All Exceptions" breakpoint set to
"Objective-C", until and if the dark day ever arrives when you need to debug a
C++ exception.
___
Coc
On Sep 25, 2013, at 10:16 AM, Kyle Sluder wrote:
> Please note that the breakpoint traps on exception *throw*. It is perfectly
> valid—daresay common—for C++ code to throw and catch exceptions as a normal
> matter of course.
Some of the system code does it, yeah; I know the innards of the Sec
> On Sep 25, 2013, at 10:00 AM, Jerry Krinock wrote:
>
>
>> On 2013 Sep 25, at 09:39, Kyle Sluder wrote:
>>
>> That looks like a C++ exception. What happens if you edit the breakpoint to
>> only break on ObjC exceptions?
>
> Thanks, Kyle. Good guess. Indeed, if I edit the breakpoint and c
On 2013 Sep 25, at 09:39, Kyle Sluder wrote:
> That looks like a C++ exception. What happens if you edit the breakpoint to
> only break on ObjC exceptions?
Thanks, Kyle. Good guess. Indeed, if I edit the breakpoint and change the
popup from "All" to "Objective-C", then it does not break whe
Some C++ developers use exceptions as a means to control the flow of their
code rather than as a means to report and handle true exceptions, and many
libraries that are part of the OS do this. In the case you mentioned, and
many others I've encountered in URL resource loading, it's often best to
n
> On Sep 25, 2013, at 9:19 AM, Jerry Krinock wrote:
>
> I think my options are…
>
> • For this special case, modify my AppleScript so as to not raise an
> exception. Maybe check for the existence of the front document before asking
> for its URL.
> • Don't use the "All Exceptions" breakpoint.
Yesterday I switched on the "All Exceptions" breakpoint in Xcode.
It breaks when my app executes an AppleScript which asks Safari for the url of
its front document, if there are no windows open in Safari. But my code can
handle if the answer is nil, and everything continues to execute just fine
10 matches
Mail list logo
