Prática recomendada - domínios e códigos NSError para seu próprio projeto / aplicativo

Há uma postagem anterior do SO sobre a configuração de domínios de erro para seus próprios frameworks, mas qual é a prática recomendada em relação à configuração de domínios de erro e códigos de erro personalizados para seu próprio projeto / aplicativo ?

Por exemplo, supondo que você esteja trabalhando em um aplicativo com uso intensivo de Core Data com muitas validações, você deve apenas ficar com os códigos de erro de Core Data "prontos para uso" (como NSManagedObjectValidationErrorde CoreDataErrors.h) ou criar seus próprios MyAppErrors.he definir erros com mais especificidade (ou seja MyAppValidationErrorInvalidCombinationOfLimbs,?

Criar um domínio de erro personalizado e um conjunto de códigos de erro pode eliminar a ambigüidade de seu código significativamente, mas é uma sobrecarga muito grande para manter e é preciso se preocupar com conflitos de numeração de código de erro? Ou existem outras preocupações aqui?

Eu pessoalmente uso um domínio de estilo DNS reverso. Por exemplo:

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

A terceira parte do domínio ( @"myproject") é usada apenas para diferenciar os erros deste projeto ( "My Project") dos erros de outro projeto ( "My Other Project"=> com.davedelong.myotherproject).

É uma maneira simples de garantir que não vou entrar em conflito com os domínios de erro de outra pessoa (se estiver usando código de terceiros), a menos que o desenvolvedor esteja propositalmente tentando mexer apenas com me (que eu acredito que seria altamente improvável. ..).

Quanto aos conflitos de numeração de código, não se preocupe com isso. Contanto que os códigos sejam exclusivos dentro de um domínio , você deve estar bem.

Quanto a erros de tradução, isso depende de você. Faça o que fizer, certifique-se de documentar bem. Pessoalmente , geralmente passo adiante os erros gerados pelo framework conforme eles chegam até mim, já que nunca tenho certeza de que vou lidar com todos os códigos e traduzir todas as informações do usuário em algo mais específico para o meu projeto. As estruturas podem alterar e adicionar mais códigos ou alterar o significado dos códigos existentes, etc. Isso também me ajuda a identificar mais especificamente de onde veio o erro. Por exemplo, se minha estrutura StackKit gerar um erro no com.stackkitdomínio, sei que é um problema de estrutura. No entanto, se gerar um erro no NSURLErrorDomain, então sei que veio especificamente do mecanismo de carregamento de URL.

O que você poderia fazer é capturar o erro quadro gerado e envolvê-la em um novo objeto de erro que tenha o seu domínio e de um código genérico, algo como kFrameworkErrorCodeUnknownou algo assim, e em seguida, coloque o erro capturado na userInfosob a NSUnderlyingErrorKey. CoreData faz muito isso (por exemplo, se você tentar save:um NSManagedObjectContext, mas tiver erros de integridade de relacionamento, receberá um único erro de volta, mas NSUnderlyingErrorKeyconterá muito mais informações, como especificamente quais relacionamentos estão errados, etc).

Não tenho representante suficiente para comentar, mas para a resposta aceita por Dave DeLong, pode ser um pouco melhor usar em [[NSBundle mainBundle] bundleIdentifier]vez de @"com.myName.myProject". Dessa forma, se você alterar o seu nome ou o nome do projeto, ele será refletido com precisão.

Como criar um NSError personalizado:

Primeiro crie um Dicionário da mensagem de erro

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];

Em seguida, atribua userInfo ao NSDictionary e pronto.