Jak rozumiem, użycie@try/@catch blokuje się, ponieważexceptions powinien być rzucany tylko w nieodwracalnych, katastrofalnych błędach (odnieś się do tej dyskusji z fajną odpowiedzią@bbum: Wyjątek Handeling w iOS).

Przejrzałem więc mój kod i znalazłem@try/@catch blok, którego nie wiem, jak się pozbyć:

NSData *fileData = [NSData dataWithContentsOfFile: ....];

NSDictionary *dictionary;

@try {
   dictionary = [NSKeyedUnarchiver unarchiveObjectWithData: fileData];
}
@catch (NSException *exception) {
   //....
}
@finally {
  //...
}

Problem polega na tym, (jak podano wdokumentacja) +unarchiveObjectWithData: podnosiNSInvalidArchiveOperationException jeśliNSData nie zawiera prawidłowego archiwum.

Ponieważ dane są dostarczane przez plik wybrany przez użytkownika, nie ma gwarancji, że zawiera ono poprawne archiwum, a zatem aplikacja ulegnie awarii, jeśli zostanie wybrany niepoprawny plik.

Teraz dwa pytania:

Dlaczego nie+unarchiveObjectWithData: po prostu wróćnil (Edytować: i anNSError**) jeśli archiwum nie jest poprawne (nie wydaje się, aby kwalifikowało się to jako błąd katastrofalny lub nieodwracalny).Czy powyższy wzór jest poprawny (używając@try)? Nie znalazłem metody, która pozwala nam sprawdzić, czy dane zawierają ważne archiwum wcześniej i nie znaleźliśmy możliwości obsługi tego przypadku przy użyciu protokołu delegata. Antyhing, które przeoczyłem?

Pamiętaj, że powyższy kod oczywiście działa, zastanawiam się tylko, czy jest to najlepsza praktyka.