cascaded do/catch bug?


(Marco S Hyman) #1

This macOS code in Xcode 8.3.3:

    if !fileManager.fileExists(atPath: (saveFileURL.path)) {
        do {
1 ==> try fileManager.linkItem(atPath: url.path, toPath: saveFileURL.path)
2 ==> } catch {
            // couldn't create hard link, copy file instead
            do {
3 ==> try fileManager.copyItem(at: url, to: saveFileURL)
            } catch let error as NSError {
                unexpected(error: error,
                           "Cannot copy \(url.path) to \(saveFileURL.path)\n\nReason: ")
                return false
            }
        }
    }
    return true

lldb tells me the code at 1 fails. That was expected. The app is sandboxed and the security bookmark code that gives access to the destination is in flux. lldb says control transfers to 2 then falls into the do block containing 3.

The code at 3 fails for the same reason. This is when the unexpected occurred. lldb says that control transferred to 2 then to the end of the if statement where the function returns true. The catch following the do containing the function “unexpected” is not entered.

Is that a bug?

As for why 1 uses path instead of URL an older version of the code had this note.

// linkItemAtURL fails trying to link foo.jpg_original to somedir/foo.jpg.


(Jordan Rose) #2

That does sound like a bug to me. Can you make a self-contained test case and file at https://bugs.swift.org/ ?

Thanks!
Jordan

···

On Jun 29, 2017, at 14:00, Marco S Hyman via swift-users <swift-users@swift.org> wrote:

This macOS code in Xcode 8.3.3:

   if !fileManager.fileExists(atPath: (saveFileURL.path)) {
       do {
1 ==> try fileManager.linkItem(atPath: url.path, toPath: saveFileURL.path)
2 ==> } catch {
           // couldn't create hard link, copy file instead
           do {
3 ==> try fileManager.copyItem(at: url, to: saveFileURL)
           } catch let error as NSError {
               unexpected(error: error,
                          "Cannot copy \(url.path) to \(saveFileURL.path)\n\nReason: ")
               return false
           }
       }
   }
   return true

lldb tells me the code at 1 fails. That was expected. The app is sandboxed and the security bookmark code that gives access to the destination is in flux. lldb says control transfers to 2 then falls into the do block containing 3.

The code at 3 fails for the same reason. This is when the unexpected occurred. lldb says that control transferred to 2 then to the end of the if statement where the function returns true. The catch following the do containing the function “unexpected” is not entered.

Is that a bug?

As for why 1 uses path instead of URL an older version of the code had this note.

// linkItemAtURL fails trying to link foo.jpg_original to somedir/foo.jpg.

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Marco S Hyman) #3

Done. SR-5339

Marc

···

On Jun 29, 2017, at 4:20 PM, Jordan Rose <jordan_rose@apple.com> wrote:

That does sound like a bug to me. Can you make a self-contained test case and file at https://bugs.swift.org/ ?