4 ms·
Because there's no way for the debugger to only break on uncaught exceptions, and you don't usually want to break on caught exceptions. Various frameworks (most
by eridius 9y ago
Because there's no way for the debugger to only break on uncaught exceptions, and you don't usually want to break on caught exceptions. Various frameworks (most infamously CoreData) use caught exceptions internally as a control flow tool.
- favorited 9y agoI've never seen this with Core Data (unless you have the multithreading-violation argument set). I do see it with some of the AV frameworks, but those are C++ exceptions, so as long as I only break on ObjC exceptions I don't hit it. Edit: I forgot 1 ObjC exception I see frequently from AVFoundation on macOS. That one does cause an annoying breakpoint hit.
- matwood 9y agoIt's been awhile since I've used CoreData, but I don't remember these being an issue.
- agildehaus 9y agoMaybe if it were the default various frameworks would be less likely to use exceptions as flow control.
- pavlov 9y agoThere are a few places in AppKit where you need to determine an object's state by catching an exception because there's no method available. (Checking whether an NSColor is a pattern comes to mind -- only way is to try getting the pattern image and it will throw if it's not a pattern color.) The really frustrating thing is that Obj-C didn't even have exceptions originally, so someone basically looked at exceptions when they were added and thought: "I know, I'll use them as part of the API"...
- saltypal 9y agoThere are some pretty solid approaches over on my SO question (particularly the lldb Python script—been using this one for years.) https://stackoverflow.com/q/14370632/798224 https://stackoverflow.com/q/14370632/798224
- marosoaie 9y agoRight, calling save on a NSManagedObjectContext often throws c++ exceptions.