Возможен ли NSError из сообщения, задокументированного где-либо?

Все ли ошибки NSError, которые могут возникнуть в результате сообщения, когда-либо задокументированы где-либо в платформах какао или iOS?

Да, типы NSErrors делятся на разные домены, но я все еще смотрю, скажем, NSURLSession, и похоже, что сообщение, такое как (NSURLSessionDownloadTask *)downloadTaskWithResumeData:(NSData *)resumeData completionHandler:(void (^)(NSURL *location, NSURLResponse *response, NSError *error))completionHandler, не указывает, какая возможная ошибка NSError может быть выброшена. А в собственном руководстве по программированию обработки ошибок Apple используется ссылка NSDocument в качестве примера, но в справочных документах также не сказано, какие ошибки могут быть выброшены.

Я что-то упускаю? Откуда программисту знать заранее, какие возможные ошибки могут произойти? Или программы обычно просто собирают все и возвращают их пользователю через оповещения?

(Я программирую для iOS)


person huggie    schedule 11.10.2013    source источник


Ответы (1)


Все ли ошибки NSError, которые могут возникнуть в результате сообщения, когда-либо задокументированы где-либо в платформах какао или iOS?

Существование NSOSStatusErrorDomain означает, что ответ отрицательный, потому что существуют буквально тысячи кодов ошибок OSStatus, и только часть из них задокументирована.

Однако большинство, если не все, ошибки в других доменах, предоставляемых Apple, задокументированы. Вы должны иметь возможность просто получить локализованное описание ошибки, локализованную причину сбоя или локализованное предложение по восстановлению, чтобы получить описание ошибки, которое (теоретически) подходит для отображения пользователю.

… Я смотрю, скажем, на NSURLSession, и кажется, что [он] не указывает, какой возможный NSError может быть выброшен. И в собственном руководстве по программированию обработки ошибок Apple в качестве примера используется NSDocument, но в справочных документах также не говорится, какие ошибки могут быть выброшены.

Набор возможных ошибок очень редко ограничен и очень часто представляет собой движущуюся цель.

Пример NSDocument — хороший пример первой части: вы можете вернуть буквально любую ошибку из методов чтения и записи. Все, что идет не так при попытке чтения (например: поврежденный/неправильный формат, бессмысленные данные) или записи (например: не удается создать файл; недостаточно места в хранилище), вы сообщаете об ошибке. Вы даже можете придумать свои собственные ошибки, и они полностью действительны, чтобы вернуться оттуда.

Даже в случае NSURLSessionDownloadTask может быть некоторый конечный набор мыслимых вещей, которые могут пойти не так, но это просто означает, что вы будете ожидать того же набора случаев сбоя, что и инженеры Apple. Когда (а не если) случится что-то, чего они не ожидали, вас тоже не будет.

«Apple никогда не говорила, что это произойдет!» является плохим оправданием того, что ваше приложение не обрабатывает ошибки должным образом.

И «никогда» может быть неверным: как я уже говорил, набор возможных ошибок может быть движущейся целью. Это означает, что Apple может расширить этот набор позже, либо потому, что они забыли одну (это случается), либо потому, что они действительно добавили другие возможные ошибки (новые коды или просто недавно обработанные случаи) позже.

Если вы ожидаете, что Apple полностью задокументирует набор текущих и будущих возможных ошибок каждого метода, вы будете разочарованы. Ожидайте несовершенства и планируйте вокруг него.

Если вы получаете сообщение об ошибке, вы должны уметь обрабатывать ЛЮБУЮ ошибку. Восстанавливайтесь из всего, что вы можете, убедитесь, что все предсказуемые невосстановимые случаи имеют разумные сообщения об ошибках (если они еще не имеют), и обработайте все остальное, вставив его локализованное описание/причину сбоя/предложение по восстановлению в предупреждении.

person Peter Hosey    schedule 11.10.2013