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.applicationIconImage will 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 a DispatchQueue that’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 NSUUID property was nil because 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 has rawValue 0. I’ve come across a handful of situations with Core Data where the 0 value 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 the enum having that case. It would probably be better to define an .invalid case with value 0 to 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 enum that’s missing a 0 case because then this situation will cause a crash when bridging to the Swift enum.)

Previously:

• SpamSieve 3.0.2
• AEDeterminePermissionToAutomateTarget Added, But AEpocalyse Still Looms