SpamSieve 3.0.3
SpamSieve 3.0.3 is another maintenance update. The main focus is working around various cases where Apple Mail doesn’t behave properly, resulting in hangs or messages not being filtered or trained.
Some interesting bugs were:
Some customers were seeing a crash when SpamSieve updated its Dock icon badging. It turns out that setting
NSApplication.applicationIconImagewill throw an exception if the image has no representations. I think this was happening due to trying to read the icon file while the application’s package was being replaced during a software update. SpamSieve now caches the image to avoid this problem, and it also checks before setting a new Dock icon to make sure that the image has a representation and a non-zero size.There’s a longstanding bug where
AEDeterminePermissionToAutomateTarget()hangs forever. SpamSieve was calling this on the main thread, so this could freeze the user interface and block reception of Apple events. SpamSieve now calls it on a background queue and adds handling of the indeterminate case where the result isn’t known yet—and may never arrive. There doesn’t seem to be a way to exit aDispatchQueuethat’s blocked, but I try to limit the number of stuck queues and avoid having the queue target a global queue, so that it won’t block the rest of the app.There was a rare crash due to accessing an absent property of a managed object. It’s not clear how this could happen, since the object was always created with that property. This managed object is never deleted, so it should not be possible for it to be a fault for an object that became inaccessible due to deletion. The only thing I can think of is that the
NSUUIDproperty wasnilbecause the database row was corrupted so that the data no longer represented a valid UUID. The managed object, if not brand-new, must have been initialized as a result of fetching by the UUID property, so perhaps the UUID data was correct in the index but not valid in the actual row.More generally, I think one mistake I made is in using
@objc enums where one of the cases hasrawValue0. I’ve come across a handful of situations with Core Data where the0value occurs only because the property wasn’t fetched, not because the object was actually saved with that value. This means that the rest of the object is inconsistent with theenumhaving that case. It would probably be better to define an.invalidcase with value0to distinguish this and to make sure that the rest of the code can handle it. (For the same reason, you should never have an@objc enumthat’s missing a0case because then this situation will cause a crash when bridging to the Swiftenum.)
Previously:
