Shared checkout cache locking for concurrent invocations #4
Conversation
| } | ||
| } | ||
|
|
||
| private static func releaseLock(lockFileURL: URL) { | ||
| _ = try? FileManager.default.removeItem(at: lockFileURL) |
There was a problem hiding this comment.
Would it be an error if removeItem fails? Maybe it would be good throw here?
There was a problem hiding this comment.
I factored the FileLock out to a separate class and implemented test cases for it. The problem with adding throws is that there is no really good way to recover from the error in case the file cannot be removed.
The most obvious reason would be that the file is already gone, in which case the error is not really an error. In all other cases (e.g. file system problems) there is no real way to recover (except maybe crashing the application). The lock will be released automatically when the process dies because of the way shlock works.
There was a problem hiding this comment.
If no recovery is possible, would it make sense to crash with a message, versus a silent failure?
No description provided.