Вы должны использовать исключения для ошибок, которые никогда не появятся, если программист проверит параметры для метода, который генерирует исключение. Например. делите на 0 или на общеизвестное исключение "вне границ", которое вы получаете от NSArrays.
NSErrors - ошибки, с которыми программист ничего не мог поделать. Например. парсинг файла plist Было бы напрасной тратой ресурсов, если бы программа проверила, является ли файл допустимым списком, прежде чем попытаться прочитать его содержимое. Для проверки правильности программа должна проанализировать весь файл. И анализ файла, чтобы сообщить, что он действителен, чтобы вы могли проанализировать его снова, был бы полной тратой. Таким образом, метод возвращает NSError (или просто nil, который сообщает вам, что что-то пошло не так), если файл не может быть проанализирован.
Парсинг на достоверность - это часть "программист должен был проверить параметры". Это не применимо для ошибок этого типа, поэтому вы не должны выдавать исключение.
Теоретически вы можете заменить исключение вне границ на return nil
. Но это приведет к очень плохому программированию.
Apple говорит:
Важно : во многих средах использование исключений является довольно распространенным явлением. Например, вы можете выдать исключение, чтобы указать, что подпрограмма не может выполняться нормально - например, когда файл отсутствует или данные не могут быть проанализированы правильно. Исключения являются ресурсоемкими в Objective-C. Вы не должны использовать исключения для общего управления потоком или просто для обозначения ошибок. Вместо этого следует использовать возвращаемое значение метода или функции, чтобы указать, что произошла ошибка, и предоставить информацию о проблеме в объекте ошибки.