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

114

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?

Neal L.
źródło

Odpowiedzi:

152

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

Dave DeLong
źródło
Ponieważ Apple używa również odwrotnego DNS, wydaje się właściwe, aby inne osoby również używały tego stylu.
Johan Karlsson
36

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.

Connor
źródło
4
Dobry pomysł. Jeśli używasz Swift, powinieneś użyć nieopakowanego opcjonalnego: NSBundle.mainBundle().bundleIdentifier!(jeśli wiesz, że identyfikator pakietu jest ustawiony, co, jak sądzę, będzie najprawdopodobniej)
Juul
Dlaczego chcesz uwzględnić zmiany nazw projektów w domenie błędów?
zrslv
1
@zrxq Na pewno warto mieć różne domeny błędów, ale wyobraź sobie, że błędnie wpisałeś swój projekt lub zmieniłeś swoje imię i nazwisko, aby było to odzwierciedlone wszędzie. Lepiej ustawić go dynamicznie niż na stałe.
Connor
1
@vare To jasne, nie bardzo rozumiem, jakie praktyczne korzyści by to przyniosło. Rozumiem, że te identyfikatory muszą być unikalne w kontekście aplikacji, to wszystko. Okay, może po prostu chcesz, żeby były bardziej estetyczne, rozumiem!
zrslv
1
Tak, poruszysz dobry punkt. Są chwile, kiedy chcesz, aby domena była unikalna, założyłbym ... na przykład jeśli tworzysz SDK lub (cocoa) Pod, chcesz, aby Twoja domena błędów odzwierciedlała, skąd pochodzi, a nie projekt imię. EDYCJA: Chciałbym również (w mojej odpowiedzi) zwrócić uwagę, że @ "com.myName.myProject" jest identyczne z bundleIdentifier w tym przypadku, którego ludzie mogą nie znać.
Connor
4

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.

Mike Zriel
źródło