On Aug 25, 2016, at 5:02 PM, Jim Ingham wrote: > Ah, maybe I was taking Carl's "apparently no reason" referencing lldb when he > meant no apparent reason in the debugee. I was concerned that he was seeing > the C++ exception breakpoint causing stops that didn't have an appropriate > stop reason in the lldb stop output or the in Xcode's pc ribbon. But > re-reading, it's quite likely that he really meant "I see no reason why this > code should be throwing exceptions". > > To help with that issue we'll have to first finish the task of reading the > actual exception object from the throw point, and providing some way to say > "don't stop for exceptions of kind X." Then you'll at least be able to pass > by exceptions you don't care about. We have radars requesting that already, > BTW... > > Jim
You're turning down good beers, Jim. I'd check your fridge before you make such a decision. And on a completely unrelated note. THANK ZEUS for Symbolic Breakpoints. I just spent 6 hours tracking down an issue that was obscured by "aggressive optimization" in one of the sub libs of an iOS project-o-pain (who needs ARC these days?) that caused the debugger to report nil in cases where the value WASN'T NIL and caused the program indicator to jump back and forth when executing some compiled code within an external lib. Well, the only way I was able to get to data and methods was by using symbolic breakpoints. When I got to the end of the problem and fixed it, 5 hours later, since the debugger and console were providing misleading status on data values AND breakpoints were ignored in the external libs, I decided to look into this aggressive optimization issue. Well, there was only one standard optimization set and that was in the Release build config of one of the linked libs for fastest, smallest. Pretty standard stuff. BUT… Some rocket surgeon has changed the build schemes for this linked lib to use the Release configuration from the Run scheme. And that caused all of the hell with a useless debugger. and console. And the whole write up to the vendor took another hour, so that's a joyous 6+ hours on one issue out of a 18 hour day. At least all the problems I've had with this code since January now have disappeared. Blessed be symbolic breakpoints. Someone's on my Christmas list for those puppies. Cheers. - Alex Zavatone _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
