LLDB crash

Same on my side, our Sysop told me last week that I generate millions of errors in the Exchange Server Logs.Deleted all Exchange accounts on El Cap mail - then it works, then I inserted the first account, it took hours to take 16k mails from Exchange server, than mail crashes again. During the download each downloaded email from Exchange to Mail generates around 50 errors in log he told me.So Apple seems to have a bug in the active sync - which is a shame! This protocol is always the same since long time.

I have the same issue the phone gets really hot. Battery doesn't last more than 3 hours standby and less than 90 minutes if I slightly use it. Crashes more than it work. Super slow. I have restored it as a new phone several times and still same issues exist as when I restore it from a backup. Hope Apple releases another beta to adress these issues soon.

This is at the top of my list as well! I have an app that has an enum with all of the countries and their country codes, and it isn't feasable to return a list of those by hand (it would easily get out of sync with the list and is a large amount of boilerplate).Here is the closest I have been able to come:protocol EnumerableEnum { static func allValues()->[Self] init?(index:Int) } extension EnumerableEnum { static func allValues()->[Self] { var idx = 0 return Array(anyGenerator{ return Self(index: idx++)}) } }If you have an Enum with integer values like so:enum TestEnum:Int,EnumerableEnum{ case A, B, C init?(index:Int){ self.init(rawValue:index) } }Then you can call the allValues() function to get a list of all values. If it doesn't have integer values, then you can implement the init method (but it doesn't buy you that much over just returning the list by hand).print(TestEnum.allValues()) // [TestEnum.A, TestEnum.B, TestEnum.C]A couple of notes:I couldn't add init?(rawValue:) to the protocol for some r

Hey, thank you ever so much for the great explanation!!! 🙂 I didn't know that NSURLSession is an asynchronous API. 😊 We're a step further; my app downloads the data as expected. There are some other problems, though: The app runs unstably now, sometimes it crashes, sometimes it doesn't. Furthermore the app is as slow as molasses in January. Also some weird display errors occur. It seems that due to the asynchronous API the table view already tries to reload by the time the data isn't loaded completely. Of course I was trying to debug the code, but how to debug when the app is running, actually? As I mentioned, the app crashes sometimes, though. Then it terminates as a result of an EXC_BAD_ACCESS, an URL timeout problem or a 'XPC connection interrupted'. But I think that these are just a red herring. The 'real problem' propably is due to my use of NSURLSession's asynchronous API; I assume that I made a mistake when notifying the delegate that the data is ready to be passed back ... A shorte

In Swift, functions and methods generally return a specific type , and the return type needs to be optional, since you might be returning nil.(There's also seems to be a Swift bug related to Self?, since trying to return Self? from your class function crashes SourceKit, so until that is fixed you couldn't return Self? anyway)You can return values from inside the do and catch blocks, so this would work for your function:extension NSRegularExpression { class func frequentlyUsedExpression() -> NSRegularExpression? { let pattern = frequently_used_pattern do { let regex = try self(pattern: pattern, options: []) return regex } catch { print(error) return nil } } }If you want subclasses of NSRegularExpression to be able to explicitly return their own type, it would be possible to create a convenience initializer that take an enum parameter and returns the appropriate pattern. (And, I think this is a cleaner way to implement it in Swift, anyway.)enum CommonRegexPatterns: String { case Pattern01 = frequent

I checked my device logs, saw lots of backupd crashes -- a few each hour. Anyone else?

What you may not grasp is that Cocoa's traditional error handling rules are still in effect:If a method fails and there's only really one failure case for it (trying to convert a non-numeric string to a number, etc.), the method returns nil or false.If an operation fails because of some complex issue with the current state of the computer (no such file, Wi-Fi turned off, etc.), the method emits an NSError. In Swift, NSErrors are handled with the do/try/catch mechanism.If an operation fails because the programmer wrote code that did something invalid (out-of-range array index, etc.), the method fails an assertion or raises an exception, which you should generally allow to crash your app. In Swift, it's not possible to catch exceptions.Creating a fetch request with an inaccurate entity name falls into that third category: failures that can only be the result of programmer error. Such problems are still handled by failing an assertion and crashing your app.

No help, I've deleted the account and re-added several times. Each time. The Y crashes system preferences.