Использовать попытку? оператор, чтобы сделать код более кратким

У меня есть этот код в Swift 2 для перемещения файла в новое место назначения, при необходимости перезаписывая:

let origin = "...", destination = "..."
do {
   try NSFileManager.defaultManager().removeItemAtPath(destination)  // remove existing file
} catch {}
do {
   try NSFileManager.defaultManager().moveItemAtPath(origin, toPath: destination)
} catch {}

Чтобы сделать код более кратким и поскольку меня не волнует выдаваемая ошибка, я подумал об использовании оператора try? следующим образом:

let origin = "...", destination = "..."
try? NSFileManager.defaultManager().removeItemAtPath(destination)
try? NSFileManager.defaultManager().moveItemAtPath(origin, toPath: destination)

Это создает предупреждение компилятора о том, что результат операции не используется, поэтому я должен добавить неиспользуемый let, и это выглядит ужасно:

...
let _ = try? NSFileManager.defaultManager().moveItemAtPath(origin, toPath: destination)

Разве плохо пускать туда предупреждения ради лаконичности?


person Iree    schedule 09.09.2016    source источник
comment
Плохо ли оставлять предупреждения ради краткости? — Большинство людей, вероятно, скажут да, но вы (или ваша компания) должны решить это. Обратите внимание, что вам не нужен let, сравните stackoverflow.com/questions/32788155/   -  person Martin R    schedule 09.09.2016
comment
_ = попробовать? NSFileManager.defaultManager().moveItemAtPath (источник, путь к пути: пункт назначения)   -  person impression7vx    schedule 09.09.2016
comment
Спасибо, звучит немного лучше!   -  person Iree    schedule 09.09.2016


Ответы (2)


В Swift 3 разрешено игнорировать результат без дополнительного присваивания. Это прекрасно компилируется без предупреждения в Xcode 8 GM:

try? FileManager.default.removeItem(atPath: destination)

(Ранее, кстати, я спрашивал об этом на bugs.swift.org, и мне прямо сказали, что этот синтаксис _ = try? считается правильным и является небольшой платой за признание компилятору — и себе — что вы преднамеренно игнорируя возвращаемое значение. Так что то, что вы делаете, просто прекрасно, пока вы остаетесь в мире Swift 2!)

person matt    schedule 09.09.2016
comment
Это законная, но плохая практика. - person mixel; 09.09.2016
comment
@mixel Я не согласен с тем, что это обязательно плохая практика. Бывают ситуации, когда не возвращается никакой полезной информации, поэтому нечего собирать, и вам может быть искренне все равно, потерпели ли вы неудачу. Показательным примером является работа с AVAudioSession. - person matt; 09.09.2016
comment
@Iree Я добавлю кое-что из этого обратно, если вы считаете, что это хорошо для потомков. - person matt; 09.09.2016
comment
@ Мэтт Я понимаю. В этом случае добавление _ = говорит о том, что я не забочусь о возврате значения другим разработчикам. В противном случае они получат предупреждение Result of 'try?' is unused' и будут сбиты с толку. Код должен быть самодокументированным. - person mixel; 09.09.2016
comment
@mixel Но я хочу сказать, что в Swift 3 такого предупреждения нет. Добавил это на случай, если я недостаточно ясно выразился. - person matt; 09.09.2016
comment
Означает ли вся эта новая 1 строка try?: Очевидно, поскольку я знаю, что запуск этой функции может вызвать ошибку. Мне нужно использовать catch, хотя я не хочу перехватывать ошибку, так что я просто напишу в одну простую строчку? - person Honey; 09.09.2016
comment
@matt Да, потому что в iOS 10 SDK / Swift 3 FileManager.removeItem имеет тип возврата Void. Но OP использует iOS 9 SDK/Swift 2, и там NSFileManager.removeItemAtPath возвращает Bool. - person mixel; 09.09.2016

Обратите внимание, что у вас есть эти предупреждения, потому что вы вызываете какой-то метод и не обрабатываете возвращаемое значение.

Если вам не нужно возвращаемое значение, вы должны использовать синтаксис let _ =, чтобы явно сообщить всем, кто читает этот код, что возвращаемое значение намеренно игнорируется.

В противном случае, если вы должны обработать возвращаемое значение, но вы еще не сделали этого, потому что вы слишком ленивы или по какой-либо другой причине, то это считается ошибкой в ​​​​вашем программном обеспечении, и вы определенно не должны ее подавлять.

person mixel    schedule 09.09.2016