J'utilise personnellement un domaine de style DNS inversé. Par exemple:
NSError * myInternalError = [NSError errorWithDomain:@"com.davedelong.myproject" code:42 userInfo:someUserInfo];
La troisième partie du domaine ( @"myproject") est juste utilisée pour différencier les erreurs de ce projet ( "My Project") des erreurs d'un autre projet ( "My Other Project"=> com.davedelong.myotherproject).
Il est un moyen simple de faire en sorte que je ne vais pas entrer en conflit avec les domaines d'erreur de quelqu'un d' autre (si je suis en utilisant le code 3ème partie), à moins que le développeur tente délibérément de mess avec juste moi (que je crois serait très improbable. ..).
En ce qui concerne les conflits de numérotation de code, ne vous inquiétez pas à ce sujet. Tant que les codes sont uniques dans un domaine , vous devriez être OK.
Quant aux erreurs de traduction, c'est à vous de décider. Quoi que vous fassiez, assurez-vous de bien le documenter. Personnellement , je ne fais généralement que transmettre les erreurs générées par le framework au fur et à mesure qu'elles me viennent, car je ne suis jamais sûr de gérer tous les codes et de traduire tous les userInfo en quelque chose de plus spécifique à mon projet. Les cadres pourraient changer et ajouter plus de codes, ou changer la signification des codes existants, etc. Cela m'aide également à identifier plus spécifiquement d'où vient l'erreur. Par exemple, si mon framework StackKit génère une erreur dans le com.stackkitdomaine, je sais que c'est un problème de framework. Cependant, s'il génère une erreur dans le NSURLErrorDomain, je sais que cela provient spécifiquement du mécanisme de chargement d'URL.
Ce que vous pouvez faire est de capturer l'erreur générée par le framework et de l'envelopper dans un nouvel objet d'erreur contenant votre domaine et un code générique, quelque chose comme kFrameworkErrorCodeUnknownou quelque chose, puis placez l'erreur capturée userInfosous le NSUnderlyingErrorKey. CoreData le fait beaucoup (par exemple, si vous essayez d' save:un NSManagedObjectContext, mais vous avez des erreurs d'intégrité des relations, vous aurez un retour simple erreur, mais NSUnderlyingErrorKeycontiendra beaucoup plus d' informations, comme spécifiquement les relations sont mauvaises, etc.).