私は個人的に逆引きDNSスタイルのドメインを使用しています。例えば:
NSError * myInternalError = [NSError errorWithDomain:@"com.davedelong.myproject" code:42 userInfo:someUserInfo];
ドメインの3番目の部分(@"myproject"
)は、このプロジェクトのエラー("My Project"
)と別のプロジェクトのエラー("My Other Project"
=> com.davedelong.myotherproject
)を区別するために使用されます。
これは、開発者が意図的に私だけを台無しにしようとしている場合を除いて、他の人のエラードメインと競合しないようにするための簡単な方法です(サードパーティのコードを使用している場合) 。 ..)。
コード番号の競合については、心配しないでください。コードがドメイン内で一意である限り、問題はありません。
エラーの翻訳に関しては、それはあなた次第です。何をするにしても、それをうまく文書化するようにしてください。 個人的には、フレームワークで生成されたエラーが発生したときに、それらを渡すだけです。すべてのコードを処理し、すべてのuserInfoをプロジェクトに固有の何かに変換するかどうかはまったくわかりません。フレームワークは、コードを変更して追加したり、既存のコードの意味を変更したりする可能性があります。また、エラーの原因をより具体的に特定するのにも役立ちます。たとえば、StackKitフレームワークがドメインでエラーを生成した場合、com.stackkit
それがフレームワークの問題であることがわかります。ただし、でエラーが発生した場合は、NSURLErrorDomain
特にURL読み込みメカニズムが原因であることがわかります。
フレームワークで生成されたエラーをキャプチャし、ドメインと汎用コードなどを含む新しいエラーオブジェクトにラップしてからkFrameworkErrorCodeUnknown
、キャプチャしたエラーをのuserInfo
下に配置しNSUnderlyingErrorKey
ます。CoreDataはこれを頻繁に行います(たとえば、を実行しようとして、save:
関係のNSManagedObjectContext
整合性エラーが発生した場合、単一のエラーが返されますが、NSUnderlyingErrorKey
具体的にどの関係が間違っているかなど、より多くの情報が含まれます)。