Lightroom SDK 4: catalog:withDo methods are not handling errors consistently.

  • 2
  • Problem
  • Updated 3 years ago
For example, when this code is attached to a button handler:

LrFunctionContext.postAsyncTaskWithContext( "tEST", function( context )

local function cleanup( a, b )
LrDialogs.message( "cleanup", "a: "..( a or 'nil' )..", b: "..( b or 'nil' ) )
end
context:addCleanupHandler( cleanup )

local ret = catalog:withWriteAccessDo( "Scratch Test", function()
error( "###1" )
end, { timeout=3 } )

LrDialogs.message( "ret: ^1", ret )

end )

Usually, it will call the cleanup handler and never make it to display "ret", like so:

, but sometimes it displays "ret: " executed, and never calls the cleanup handler, opting instead for a generic "internal error" message (after "ret" dialog box is dismissed), i.e.:

then, after dimissal of the above:


This inconsistency is making it quite the challenge to provide reliable consistent error handling in plugins which access the catalog.

Bonus problem:
-------------------
The documentation does not mention what the correct behavior should be when an error *is* thrown in called function:

Return value
(string) If 'func' does not throw an error, the returned string will be either "executed", "queued", or "aborted".


Thanks,
Rob
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes

Posted 5 years ago

  • 2
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
Note: behavior *is* consistent when timeout parameter is omitted.

I am thus reverting all Lr4 code to old-style Lr3 catalog access methodology, which opts for a hold-off by random amount of time, retry, and then repeat, if necessary, for a while, when there are catalog contention errors, in order to gain catalog access, as a work-around until this bug is fixed.

UPDATE: Oh yeah - much better (whew! - what I relief: this bug has been haunting my Lr4 plugins for a while now). Timeout param table: good idea, but not quite ready for prime time.

I recommend all plugin authors refrain from using timeout param table and institute a hold-off/retry scheme instead - you really have to do that anyway if you want your plugin to work well (in all contexts) in Lr3, and it works just as nicely in Lr4.

I will be re-considering use of timeout-param table when Lr5 is released, if this bug is fixed, and it works for both Lr4 & Lr5, in cases where Lr3 support is to be discontinued.

If you need a reference for how to code to support Lr3 & Lr4 with the same code you can find it in any of my plugins Framework/Catalog folder, Catalog.lua module.

Rob
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
Just gave a brief try in Lr5(.3RC) - this bug seemed to be fixed.

So, I'll try using the timeout params again (on a trial basis) *iff* Lr5, and see how it goes - will report back..
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
Trial has gone well, so in Lr5+ the new timeout parameter is being used in production code. In Lr4-, the old Lr3 compatible code is still being used.