Почему Error всегда будет NSError?

У меня есть следующий класс, определенный на игровой площадке с Swift 3:

class MyError: Error {

}

Затем я создаю экземпляр такого класса и проверяю, является ли он NSError

let firstError = MyError()
firstError is NSError // Output: false

Вывод соответствует ожидаемому, и я также получаю предупреждение, которое указывает Cast from 'MyError' to unrelated type 'NSError' always fails. Для меня это имеет смысл, но если я немного изменю код и объявлю переменную как Error, я получу странный результат:

var secondError: Error
secondError = MyError()
secondError is NSError // Output: true

И в этом случае я получаю предупреждение в последней строке, которая говорит 'is' test is always true. Я не понимаю, почему Error всегда будет NSError, когда модель определяется наоборот (NSError: Error). Любая идея, что здесь происходит?


person Matias    schedule 30.11.2016    source источник
comment
Я думаю, что это связано: stackoverflow.com/ вопросы/39033194/   -  person 0x416e746f6e    schedule 01.12.2016
comment
Поскольку компилятор может принудить Error к NSError. Быстрый поиск в репозитории Swift нашел следующее: github .com/apple/swift/blob/   -  person Bryan Chen    schedule 01.12.2016
comment
Я столкнулся с аналогичной проблемой при сопоставлении шаблонов NSErrors в операторах switch. Я нашел этот пост в блоге полезным: figure.ink/blog/2017 /7/24/update-matching-nserrors Очевидно, есть какое-то причудливое приведение NSError к структурам, но не уверен, что это применимо.   -  person TMin    schedule 05.04.2018


Ответы (1)


Это преднамеренное поведение, позволяющее типам Swift Error взаимодействовать с Objective-C.

Компилятор будет выполнять принуждение только при соединении ошибок Swift с Objective-C или в вашем случае, когда все, что у вас есть, это Error экзистенциал, который может содержать что угодно... помните, что он мог точно так же исходить из throws функции, написанной на Objective-C -С. Это также дает вам возможность получить принуждение, если вам нужно передать NSError непосредственно какому-либо методу Objective-C в качестве параметра (по какой-либо причине).

person russbishop    schedule 16.04.2017