9 ms·
Xcode 9.1 Improves Display of Fatal Errors
- M4v3R 9y agoThis is one of those "how the hell Xcode didn't have this already?" type of things. A very welcome change, I personally don't do much iOS development but got those EXC_BAD_INSTRUCTION errors in past and they were always very misleading to me.
- bernadus_edwin 9y agoRename refactoring swift also finally came after 2 years. Maybe xcode product manager is replaced by someone who more understand developer. Every release on xcode 9 has big impact. Gladly apple now hear developer. Before this, xcode 8 is the worst IDE
- flipgimble 9y agoOr more realistically and less dramatically, some these big features took a lot of effort and engineering investment before they were ready for production. Apple tends to re-think the current technology and implements their ideal solution. This takes longer but avoids the duck tape approach I've seen in various iterations of Visual Studio. As a concrete example the refactoring tools in Xcode9 work for both C++ (for the first time!), Objective-C and Swift using the same framework. Best of all the API to write your own refactoring tools has been carefully designed, and there have been some high quality external contributions already to the refactoring tools.
- symlinkk 9y agoWhat's wrong with the way Visual Studio does things?
- binthere 9y agoI actually think Visual Studio does refactoring pretty well. It is not a new innovation from Apple. Xcode, in this case, is just catching up with a much needed feature and I still think it's not quite there.
- favorited 9y agoIt looks the implementation was a significant investment. They built a language-agnostic refactoring engine into Clang and open-sourced it http://lists.llvm.org/pipermail/cfe-dev/2017-June/054286.html http://lists.llvm.org/pipermail/cfe-dev/2017-June/054286.htm...
- valuearb 9y agoXcode 8 is still better, because Xcode 8 actually works. Xcode 9.2 might be great, but 9.1 doesn't seem to take any interest in the most urgent problems of 9.0, i.e everything breaks as SourceKit grinds relentlessly in the background chewing up more and more memory (it reached 18 gigs physical ram on my 16 gig MacBook somehow!). First it forgets how to find symbols, or refactor, then text entry slows so much until I have to wait a few seconds every time I type just to see what I typed, finally the editor just freezes for lengthy periods. That's just the most prominent problems. Fortunately restart fixes these problems, but not most others.
- xenadu02 9y agoThis kind of problem is almost always extremely project-specific. There are an infinite variety of compiler flags, custom build steps, etc. Set "defaults write com.apple.dt.Xcode IDESourceKitServiceLogLevel 3" and SourceKit will write a log to /tmp with all the details of what it is doing while indexing. A lot of people find they have header hygiene problems or module problems that happen to work while building in certain configurations but aren't actually correct, resulting in missing modules or broken headers from the indexer's point of view. Dealing with C/C++ headers, includes, modules, et al is part of the reason a lot of editors never bother with trying to offer complicated refactoring, autocomplete, etc. It is far from trivial no matter what build system you are using. If you file a bug report and attach your project someone on the indexer team will personally take a look.
- valuearb 9y agoThank you.
- slavapestov 9y agoIf you can, you should file a radar and attach a copy of your project.
- valuearb 9y agoi need company approval but will try.
- 0x0 9y agoIs this the first time a feature is exclusive to swift, and not available for Objective-C? I wish they would offer this for regular Objective-C apps as well. UIApplication is an objc class after all!
- Someone 9y agoObjective-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.
- nielsbot 9y agonot entirely true. if you use Obj-C data types (NSArray etc) you get an exception for out-of-range accesses.
- 0x0 9y agoRight, 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?
- eridius 9y agoStick `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).
- 0x0 9y agoThanks 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 :)
- jarjoura 9y ago> Note that this improved experience is only available when the app’s entry point is written in Swift (i.e. your app delegate with the @UIApplicationMain/@NSApplicationMain attribute). Interesting requirement, is this because it requires a predictable entry codepath in order to work?
- eridius 9y agoI'm guessing because it has to insert code into main() to set up the coordination with Xcode. EDIT: Ok, I looked into it. There's no code inserted into main(). The way this works is Xcode sets up an internal breakpoint on _swift_runtime_on_report, which is an empty function that is called during fatal errors specifically to allow Xcode to break on it. I don't know why this requires main() to be written in Swift.
- nielsbot 9y agoand/or some type of custom exception/signal handler?
- deleted 9y ago[deleted]
- matwood 9y agoOne thing I've never understood is why break on all exceptions is not the default in Xcode. It'll happy crash the app with an assembly stack trace with no way to see the offending code unless break on all exceptions is setup.
- eridius 9y agoBecause 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"...
- woolvalley 9y agoSo if we use swift to write our main function and call UIApplicationMain, then this wouldn't apply?
- eridius 9y agoYeah it does. I tested a CLI app in Xcode 9.1 which was just a single main.swift file and it showed my fatalError() nicely.
- applecorruption 9y agoXcode have soo so many places where it need to be fixed. No wonder why people rather use android studio. And swift version is changing every 6 momths to ruin everything.. good luck