It's not available for Obj-C because this has to do with a Swift-only feature. The closest equivalent in Obj-C is throwing exceptions.

Objective-C is C; it doesn’t do the various range and nil checks that Swift does to exit properly.

Because of that, it cannot do that.

Obj-C got _Nonnull and _Nullable type annotations as hints to the compiler. Presumably those checks could get compiled in as well?

https://developer.apple.com/swift/blog/?id=25

not entirely true. if you use Obj-C data types (NSArray etc) you get an exception for out-of-range accesses.

Right, I feel like I've seen exceptions for a lot of errors ending up with xcode hanging on an exc_bad_whatever disassembly of some sort of main() routine, things like putting nil values in arrays, inconsistent uitableview datasource implementations, etc. Usually shows an alright stack trace logged to the console but the main xcode editor still opens a useless disassembler in system code?

Stick `po $arg1` in your exception breakpoint and it will print the exception (well, for Obj-C exceptions; I don't remember offhand how to look at C++ exceptions since I so rarely deal with them).

Thanks for the tip. It's usually not a problem to figure out what's wrong (the exception is dumped to the debugger), but it's a bit useless that the main editor in xcode switches to an irrelevant disassembly view at the same time :)

It shouldn't. Xcode usually switches to the shallowest stack frame that has source code available when hitting a breakpoint.

Oh, I was talking about uncaught exceptions where no breakpoint has been set.

Uncaught exceptions don't enter the debugger until it bubbles back up to main(), so the stack in the debugger is useless there.

Right, I was hoping this new Xcode 9.1 feature could improve upon that for Objective-C as well. Perhaps capturing a copy of the stack when the exception is raised, so it open the main editor window on the appropriate source line where that exception was raised.