2012-12-10 15 views
6

Próbuję znaleźć informacje na temat obsługi błędów podczas tworzenia stałego koordynatora sklepu w telefonie iPhone. Wdrożyłem lekką migracjęObsługa błędów w addPersistentStoreWithType

NSError *error = nil; 
NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys: 
         [NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption, 
         [NSNumber numberWithBool:YES], NSInferMappingModelAutomaticallyOption, nil]; 
_persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]]; 
if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:options error:&error]) { 
    /* 
    Replace this implementation with code to handle the error appropriately. 

    abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development. 

    Typical reasons for an error here include: 
    * The persistent store is not accessible; 
    * The schema for the persistent store is incompatible with current managed object model. 
    Check the error message to determine what the actual problem was. 


    If the persistent store is not accessible, there is typically something wrong with the file path. Often, a file URL is pointing into the application's resources directory instead of a writeable directory. 

    If you encounter schema incompatibility errors during development, you can reduce their frequency by: 
    * Simply deleting the existing store: 
    [[NSFileManager defaultManager] removeItemAtURL:storeURL error:nil] 

    * Performing automatic lightweight migration by passing the following dictionary as the options parameter: 
    @{NSMigratePersistentStoresAutomaticallyOption:@YES, NSInferMappingModelAutomaticallyOption:@YES} 

    Lightweight migration will only work for a limited set of schema changes; consult "Core Data Model Versioning and Data Migration Programming Guide" for details. 

    */ 
    NSLog(@"Unresolved error %@, %@", error, [error userInfo]); 
    abort(); 
}  

return _persistentStoreCoordinator; 

Jest to oparte na kodzie firmy Apple z dodaną obsługą migracji lekkiej.

Nie mogę znaleźć żadnych informacji na temat obsługi błędów, jeśli aplikacja nadal napotyka błąd tutaj. Wydaje mi się, że jeśli nie można utworzyć bazy danych, aplikacja nie może być w ogóle użyta.

  • Czy po prostu proszę użytkownika, aby ponownie zainstalował aplikację i wyświetlił odpowiedni infromation?
  • Czy mogę zachować instrukcję abort(), dodając monit o błąd lub czy spowoduje to odrzucenie aplikacji przez Apple?

Odpowiedz

14

Wywołanie abort() w tej sytuacji nie wchodzi w grę. Każda aplikacja, która ulegnie awarii, zostanie odrzucona przez firmę Apple. I to nie rozwiązuje problemu: Ponowne uruchomienie aplikacji spowoduje odnalezienie tego samego pliku sklepu, a tym samym ponowne uruchomienie.

Z tego samego powodu ponowna instalacja aplikacji nie pomoże i byłaby to zła obsługa.

Oczywiście sytuacja nie powinna wystąpić, jeśli migracja została przetestowana. Ale jeśli wystąpi ten błąd krytyczny, a twoja aplikacja nie może otworzyć bazy danych, musisz utworzyć świeżą bazę danych.

Dokładne czynności, które należy podjąć, zależą od tego, co jest przechowywane w bazie danych i czy/jak można odzyskać dane. Więc można

  • usunąć stary plik bazy danych z [[NSFileManager defaultManager] removeItemAtURL:storeURL error:nil] lub skopiuj domyślny plik bazy danych z zasobów programów do storeURL,
  • połączenia _persistentStoreCoordinator addPersistentStoreWithType:... ponownie otworzyć nową bazę danych.
  • Być może wypełnij bazę danych ponownie danymi z serwera lub cokolwiek zrobić, aby odtworzyć dane.
+0

Dziękuję za pomoc Dodałem próbę usunięcia bazy danych, a następnie utworzenie jej ponownie, ponieważ bazy danych nie można załadować z serwera. Jeśli nadal nie działa, co mogę zrobić? –

+1

To byłby błąd krytyczny, który nie powinien wystąpić normalnie, więc * myślę, że w takim przypadku byłoby OK, aby przerwać(), aby uzyskać logi awarii, które informują o problemie. –