Najlepsza praktyka - domeny i kody NSError dla własnego projektu / aplikacji

Istnieje poprzedni post dotyczący konfigurowania domen błędów dla własnych frameworków, ale jaka jest najlepsza praktyka dotycząca konfigurowania domen błędów i niestandardowych kodów błędów dla własnego projektu / aplikacji ?

Na przykład, przypuśćmy, że pracujesz nad aplikacją intensywnie korzystającą z podstawowych danych z dużą liczbą walidacji, czy po prostu trzymaj się „gotowych” kodów błędów podstawowych danych (takich jak NSManagedObjectValidationErrorod CoreDataErrors.h), czy też tworzysz własne MyAppErrors.hi definiujesz błędy za pomocą więcej swoistość (tzn MyAppValidationErrorInvalidCombinationOfLimbs?

Utworzenie niestandardowej domeny błędów i zestawu kodów błędów może znacznie ujednoznacznić kod, ale czy jest to zbyt duże obciążenie w utrzymaniu i czy należy się martwić konfliktami numeracji kodów błędów? A może są tu inne obawy?

Osobiście używam domeny typu reverse-DNS. Na przykład:

NSError * myInternalError = [NSError errorWithDomain:@"com.davedelong.myproject" code:42 userInfo:someUserInfo];

Trzecia część domeny ( @"myproject") służy po prostu do odróżnienia błędów z tego projektu ( "My Project") od błędów w innym projekcie ( "My Other Project"=>com.davedelong.myotherproject ).

Jest to prosty sposób, aby upewnić się, że nie będę w konflikcie z domenami błędów innych osób (jeśli używam kodu innej firmy), chyba że ten programista celowo próbuje zadzierać tylko ze mną (co moim zdaniem byłoby bardzo mało prawdopodobne. ..).

Jeśli chodzi o konflikty numeracji kodów, nie martw się o to. Tak długo, jak kody są unikalne w domenie , wszystko powinno być w porządku.

Jeśli chodzi o tłumaczenia błędów, to zależy od Ciebie. Cokolwiek robisz, upewnij się, że dobrze to udokumentujesz. Osobiście zwykle po prostu przekazuję błędy generowane przez framework, gdy do mnie dotarły, ponieważ nigdy nie jestem do końca pewien, czy obsłużę wszystkie kody i przetłumaczę wszystkie informacje o użytkowniku na coś bardziej specyficznego dla mojego projektu. Struktury mogłyby zmieniać i dodawać więcej kodów lub zmieniać znaczenie istniejących kodów, itp. Pomaga mi to również w dokładniejszym zidentyfikowaniu źródła błędu. Na przykład, jeśli mój framework StackKit generuje błąd w com.stackkitdomenie, wiem, że jest to problem z frameworkiem. Jeśli jednak generuje błąd wNSURLErrorDomain , to wiem, że pochodzi on konkretnie z mechanizmu ładowania adresu URL.

Co mógł zrobić, to uchwycić błąd ramową generowane i owinąć go w nowym obiekcie o błędzie, który ma swoją domenę i kod ogólny, coś kFrameworkErrorCodeUnknownlub coś, a następnie umieścić przechwycony błąd w userInforamach NSUnderlyingErrorKey. CoreData robi to dużo (na przykład, jeśli spróbujesz , ale trzeba błędów integralności związek, dostaniesz pojedynczego błędu plecy, ale będzie zawierać znacznie więcej informacji, jak konkretnie których relacje są złe, etc).save:NSManagedObjectContextNSUnderlyingErrorKey

Nie mam wystarczającej liczby przedstawicieli, aby komentować, ale dla zaakceptowanej odpowiedzi Dave'a DeLonga może być nieco lepiej użyć [[NSBundle mainBundle] bundleIdentifier]zamiast @"com.myName.myProject". W ten sposób, jeśli zmienisz swoją nazwę lub nazwę projektu, zostanie to dokładnie odzwierciedlone.

Jak stworzyć niestandardowy NSError:

Najpierw utwórz słownik komunikatu o błędzie

NSDictionary *userInfo = @{   
   NSLocalizedDescriptionKey: NSLocalizedString(@"Unknown Error - Please try again", nil),
   NSLocalizedFailureReasonErrorKey: NSLocalizedString(@"Unknown Error - Please try again", nil),
   NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString(@"Unknown Error - Please try again", nil)
                                               };
NSError *error = [NSError errorWithDomain:[[NSBundle mainBundle] bundleIdentifier] 
  code:-58 userInfo:userInfo];

Następnie przypisz informacje o użytkowniku do NSDictionary i gotowe.