Because I’ve encountered some problems, and found ways around them, but never documented them. I’m doing that now.
So. I’ve got network communication that returns a JSON object. Which means I need to run it in an asynchronous task, because Lightroom doesn’t allow network communication anywhere else. And I also need it to run silently, without pestering the user about errors.
And thus, I’ve got checks for Lightroom network errors, server errors (status < 299) and errors in the returned JSON. All’s well and good, right?
Nope. Malformed JSON is still a problem. (Unexpected, but still.)
I’m using Jeffery Friedl’s JSON library, which throws assert(false, message) when it runs into problems parsing. (In theory, I can override the assert method. However, in practice, I haven’t managed it. Tried 8 different ways before giving up, according to my Git history.)
Now, you might think, “Ok, LrFunctionContext has addFailureHandler, let’s wrap that in an asyncWithoutErrorHandler task.” Which is what I thought too. Turns out, Lightroom doesn’t like it when you have a function context *within* an async task – probably something about mucking around with contexts.
Ok. So, swap it around? LrFunctionContext outside, async task inside? Something like this? Er, yeah… the cleanup handler? Never gets called. (Which is a bit strange. I’d have expected the cleanup handler to get called in any case, but it seemed not to. I might go back and retry it. Probably not. My gut says this has to do with the order the handlers were called in.)
But that makes a twisted sort of sense. An async task just returns nil (SO DO ALL YOUR PROCESSING INSIDE THE TASK!), so I suppose there wasn’t any failure from Lightroom’s point of view, so the failure cleanup never got called.
But all this doesn’t solve our main problem – how do we suppress the error dialog, but still continue to process?
The answer is postAsyncTaskWithContext. By default it seems to suppress error messages, and still allows you to add cleanup/failure handlers.
Just be careful what order you add them in – failure handlers should go last. If the cleanup is called last, the failure handler never seems to get called for some reason. Though now that I actually test it… it seems to be working fine. Yeesh.