Контакт с ошибками
Почти каждое приложение встречается с ошибками. Некоторые из этих ошибок будут за пределами Вашего управления, такого как исчерпывание дискового пространства или потеря сетевого соединения. Некоторые из этих ошибок будут восстанавливаемыми, такими как ввод недействительного пользователя. И, в то время как все разработчики борются за совершенство, случайная ошибка программиста может также произойти.
Если Вы приезжаете из других платформ и языков, можно привыкнуть работать за исключениями на большинство обработки ошибок. Когда Вы пишете код с Objective C, исключения используются исключительно для ошибок программиста, как за пределы доступ к массиву или параметры недопустимого метода. Это проблемы, которые необходимо найти и фиксировать во время тестирования перед поставкой приложения.
Все другие ошибки представлены экземплярами NSError
класс. В этой главе приведено краткое введение в использование NSError
объекты, включая то, как работать с методами платформы, которые могут привести к сбою и возвратить ошибки. Для получения дополнительной информации см. Руководство по программированию Обработки ошибок.
Используйте NSError для большинства ошибок
Ошибки являются неизбежной частью жизненного цикла любого приложения. Если необходимо запросить данные от удаленного веб-сервиса, например, существует множество потенциальных проблем, которые могут возникнуть, включая:
Никакое сетевое соединение
Удаленный веб-сервис может быть недоступным
Удаленный веб-сервис может не быть в состоянии служить информации, которую Вы запрашиваете
Данные, которые Вы получаете, могут не соответствовать то, что Вы ожидали
К сожалению, не возможно создать планы непредвиденных обстоятельств и решения для каждой мыслимой проблемы. Вместо этого необходимо запланировать ошибки и знать, как иметь дело с ними для предоставления самого лучшего пользовательского опыта.
Некоторые методы делегата предупреждают Вас к ошибкам
Если Вы реализуете объект делегата для использования с классом платформы, выполняющим определенную задачу, как загрузка информации от удаленного веб-сервиса, то Вы будете обычно находить, что необходимо реализовать по крайней мере один связанный с ошибкой метод. NSURLConnectionDelegate
протокол, например, включает a connection:didFailWithError:
метод:
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error; |
Если ошибка произойдет, то этот метод делегата вызовут для обеспечения Вас NSError
объект описать проблему.
NSError
объект содержит числовой код ошибки, домен и описание, а также другую релевантную информацию, упакованную в пользовательском информационном словаре.
Вместо того, чтобы делать требование, чтобы каждая возможная ошибка имела уникальный числовой код, Какао и Сенсорные ошибки Какао разделены на домены. Если ошибка происходит в NSURLConnection
, например, connection:didFailWithError:
метод выше обеспечит ошибку от NSURLErrorDomain
.
Ошибочный объект также включает локализованное описание, такое как “Сервер с указанным именем хоста не мог быть найден”.
Некоторые ошибки передачи методов ссылкой
Некоторое Касание Какао и Какао API пасует назад ошибки ссылкой. Как пример, Вы могли бы решить хранить данные, которые Вы получаете от веб-сервиса путем записи его в диск, с помощью NSData
метод writeToURL:options:error:
. Последний параметр к этому методу является ссылкой на NSError
указатель:
- (BOOL)writeToURL:(NSURL *)aURL |
options:(NSDataWritingOptions)mask |
error:(NSError **)errorPtr; |
Перед вызовом этого метода необходимо будет создать подходящий указатель так, чтобы можно было передать его адрес:
NSError *anyError; |
BOOL success = [receivedData writeToURL:someLocalFileURL |
options:0 |
error:&anyError]; |
if (!success) { |
NSLog(@"Write failed with error: %@", anyError); |
// present error to user |
} |
Если ошибка происходит, writeToURL:...
метод возвратится NO
, и обновление Ваш anyError
указатель для указания на ошибочный объект на описание проблемы.
При контакте с ошибками, переданными ссылкой, важно протестировать возвращаемое значение метода, чтобы видеть, произошла ли ошибка, как показано выше. Только протестируйте, чтобы видеть, был ли ошибочный указатель установлен указать на ошибку.
Восстановитесь если Возможный или Дисплей Ошибка Пользователю
Лучший пользовательский опыт для Вашего приложения для восстановления прозрачно с ошибки. При создании удаленного веб-запроса, например, Вы могли бы попытаться обратиться с просьбой снова с различным сервером. Также Вы, возможно, должны были бы запросить дополнительную информацию от пользователя, такого как допустимые учетные данные имени пользователя или пароля перед тем, чтобы попробовать еще раз.
Если не возможно восстановиться с ошибки, необходимо предупредить пользователя. Если Вы разработаете с Касанием Какао для iOS, то необходимо будет создать и сконфигурировать a UIAlertView
вывести на экран ошибку. Если Вы разрабатываете с Какао для OS X, можно вызвать presentError:
на любом NSResponder
объект (как представление, окно или даже сам объект приложения) и ошибка распространит цепочку респондента для дальнейшей конфигурации или восстановления. Когда это достигает объекта приложения, приложение представляет ошибку пользователю через предупредительную панель.
Для получения дополнительной информации о представлении ошибок пользователю посмотрите информацию об Отображении От Ошибочных Объектов.
Генерация собственных ошибок
Для создания собственного NSError
объекты необходимо будет определить собственный ошибочный домен, который должен иметь форму:
com.companyName.appOrFrameworkName.ErrorDomain |
Необходимо будет также выбрать уникальный код ошибки для каждой ошибки, которая может произойти в домене, вместе с подходящим описанием, которое сохранено в пользовательском информационном словаре для ошибки, как это:
NSString *domain = @"com.MyCompany.MyApplication.ErrorDomain"; |
NSString *desc = NSLocalizedString(@"Unable to…", @""); |
NSDictionary *userInfo = @{ NSLocalizedDescriptionKey : desc }; |
NSError *error = [NSError errorWithDomain:domain |
code:-101 |
userInfo:userInfo]; |
Этот пример использует NSLocalizedString
функция для поиска локализованной версии описания ошибки от a Localizable.strings
файл, как описано в Локализации Строковых ресурсов.
Если необходимо пасовать назад ошибку ссылкой, как описано ранее, сигнатура метода должна включать параметр для указателя на указатель на NSError
объект. Необходимо также использовать возвращаемое значение для указания успешности или неуспешности, как это:
- (BOOL)doSomethingThatMayGenerateAnError:(NSError **)errorPtr; |
Если ошибка происходит, необходимо запустить путем проверки ли не -NULL
указатель был предоставлен для параметра ошибок, прежде чем Вы попытаетесь разыменовать его для установки ошибки перед возвратом NO
указать отказ, как это:
- (BOOL)doSomethingThatMayGenerateAnError:(NSError **)errorPtr { |
... |
// error occurred |
if (errorPtr) { |
*errorPtr = [NSError errorWithDomain:... |
code:... |
userInfo:...]; |
} |
return NO; |
} |
Исключения используются для ошибок программиста
Objective C поддерживает исключения почти таким же способом как другие языки программирования с подобным синтаксисом к Java или C++. Как с NSError
, исключения в Касании Какао и Какао являются объектами, представленными экземплярами NSException
класс
Если необходимо записать код, который мог бы заставить исключение быть брошенным, можно включить тот код в блоке try-catch:
@try { |
// do something that might throw an exception |
} |
@catch (NSException *exception) { |
// deal with the exception |
} |
@finally { |
// optional block of clean-up code |
// executed whether or not an exception occurred |
} |
Если исключение выдается кодом в @try
блок, это будет поймано @catch
блокируйте так, чтобы можно было иметь дело с ним. Если Вы работаете с низкоуровневой библиотекой C++, использующей исключения для обработки ошибок, например, Вы могли бы поймать ее исключения и генерировать подходящий NSError
объекты вывести на экран пользователю.
Если исключение выдано и не поймано, обработчик необработанных исключений по умолчанию регистрирует сообщение к консоли и завершает приложение.
Вы не должны использовать блок try-catch вместо стандартных программных проверок на методы Objective C. В случае NSArray
, например, необходимо всегда проверять массив count
определить число элементов прежде, чем попытаться получить доступ к объекту в данном индексе. objectAtIndex:
метод выдает исключение, если Вы делаете за пределы запрос так, чтобы можно было найти ошибку в коде рано в цикле разработки — необходимо избежать выдавать исключения в приложении, которое Вы поставляете пользователям.
Для получения дополнительной информации об исключениях в приложениях Objective C посмотрите, что Исключение Программирует Темы.