Обработка исключений при выпуске / выпуске iPhone

Question

Заранее, пожалуйста, извините, что я не понимаю, для iPhone / Objective-C Best Practices;Я пришел из .NET / C # фона.

Хотя я прочитал много постов, касающихся обработки исключений для iPhone, я до сих пор не совсем понимаю, что большинство людей делают для производственного кода.Кроме того, я не смог найти никаких приложений с открытым исходным кодом с обработкой ошибок, которые я обычно ожидаю.Вот мои вопросы:

1) Если произойдет непредвиденный результат, который может привести к сбою приложения в конечном итоге, вы сгенерируете исключение или просто дождитесь его сбоя позже?Например,

if (![fileManager createDirectoryAtPath: myNewDir
    withIntermediateDirectories: YES 
    attributes: nil 
    error: &myError]) {

    // My app shouldn't continue. Should I raise an exception? 
    // Or should I just log it and then wait for it to crash later?
}

2) Проверяете ли вы параметры?Например, в C # я обычно проверял бы наличие нуля и, если необходимо, выбрасывал исключение ArgumentNullException.

3) Когда происходит сбой приложения, регистрируется ли информация о сбое автоматически или мне нужно установить обработчик необработанных исключений?Могу ли я показать UIAlertView в этом методе, чтобы сообщить пользователю, что случилось что-то плохое, вместо того, чтобы приложение просто исчезло?(Если это так, я не мог заставить его работать.)

4) И наконец, почему я не вижу, чтобы кто-то действительно использовал @ try / @ catch / @ finally?Он широко используется в C #, но я не нашел приложений с открытым исходным кодом, использующих его.(Может быть, я просто смотрю на неправильные приложения.)

Answer 1

Объявление 1. Пример, который вы приводите, является несколько классическим примером того, когда следует использовать «проверенное исключение» в Java. Вызывающий метод должен быть готов к тому, что вызов может потерпеть неудачу по причинам, которые находятся за пределами того, что он может контролировать. В частности, в данном примере я бы позволил объекту дескриптора ошибки разрешить распространение обратно к вызывающей стороне:

- (BOOL) prepareDirectories: (NSString*) path error: (NSError**) location {

    if( ![fileManager createDirectoryAtPath: path
                      withIntermediateDirectories: YES 
                      attributes: nil 
                      error: location] ) {

        return NO;
    }

    // ... additional set-up here
    return YES;
}

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

Объявление 2. Да, проверка параметров - это определенно то, что вы должны сделать. И повышение исключения для неожиданных nil с вполне уместно. Неверный параметр - это «ошибка программиста», и вы не можете гарантировать, что программа все еще находится в согласованном состоянии. Например, NSArray вызывает исключение, если вы пытаетесь получить элемент, используя несуществующий индекс.

Объявление 3. Когда приложение вылетает из-за необработанного исключения, этот факт регистрируется автоматически. Вы можете поймать исключение, если вы действительно хотите отобразить сообщение об ошибке. Тем не менее, приложение, скорее всего, находится в противоречивом состоянии, и его нельзя допускать продолжения, поэтому простое его отключение кажется лучшим решением.

Объявление 4. Я не знаю.

Answer 2

1. В конкретном случае, о котором вы упоминаете, вы должны предоставить пользователю уведомление о том, что только что произошло, с инструкциями о том, как исправить ситуацию. За исключением крайних случаев, ваше приложение не должно закрываться. Вы должны позволить пользователю исправить все, что не так, а затем повторите попытку.
2. Проверка параметров зависит от множества факторов. Следует иметь в виду, что в Obj-C вполне допустимо отправлять сообщения на nil (если вы этого не сделаете), поэтому во многих ситуациях вам не нужно проверять на ноль. Если я в классе модели, я всегда проверяю параметры в методах. Если я не прав, я почти никогда ничего не проверяю, проверка типов достаточно хороша.
3. Некоторая информация должна регистрироваться, но всегда полезно регистрировать более конкретную информацию в вашей ситуации. В идеале вы никогда не должны достигать необработанного состояния исключения.
4. Классы какао редко генерируют исключения по экологическим причинам, они почти всегда, потому что вы сделали что-то не так. Например, вы обычно не ставили бы блок @ try / @ catch вокруг [NSString stringWithString:], потому что единственный способ вызвать исключение - это если вы попытаетесь передать nil. Убедитесь, что вы не передаете nil, и вам не придется беспокоиться об обнаружении исключений. Когда метод может потерпеть неудачу из-за чего-то вне вашего контроля, они обычно обмениваются сообщениями через NSError. См., Например, - (BOOL)save:(NSError **)error метод NSManagedObjectContext.