ベストプラクティス-独自のプロジェクト/アプリのNSErrorドメインとコード

114

独自のフレームワークのエラードメインの設定に関する以前のSOの投稿がありますが、独自のプロジェクト/アプリのエラードメインとカスタムエラーコードの設定に関するベストプラクティスは何ですか？

たとえば、多数の検証を伴うCore Data集中型のアプリで作業している場合、「既製」のCore Dataエラーコード（NSManagedObjectValidationErrorからなど）をそのままCoreDataErrors.h使用するか、独自のコードを作成してMyAppErrors.hエラーを定義する必要がありますより特異性（すなわち、MyAppValidationErrorInvalidCombinationOfLimbs？

カスタムエラードメインとエラーコードのセットを作成すると、コードが明確になりますが、維持するのにオーバーヘッドが多すぎて、エラーコード番号の競合を心配する必要がありますか？または、ここに他の懸念がありますか？

— ニールL
ソース

回答:

152

個人的には、逆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れますが、具体的にはどの関係が間違っているかなど、より多くの情報が含まれます）。

— デイブ・デロング
ソース

AppleもリバースDNSを使用しているため、他のユーザーもこのスタイルを使用するのが適切と思われます。

— Johan Karlsson、2015年

私にはコメントするのに十分な担当者がいませんが、Dave DeLongの承認された回答については、の[[NSBundle mainBundle] bundleIdentifier]代わりに使用する方が少し良いかもしれません@"com.myName.myProject"。これにより、名前やプロジェクト名を変更しても、正確に反映されます。

— コナー
ソース

良いアイデア。Swiftを使用している場合は、ラップされていないオプションを使用する必要がありますNSBundle.mainBundle().bundleIdentifier!（バンドルIDが設定されていることがわかっている場合、おそらくそれが当てはまると思います）

— Juul

プロジェクト名の変更をエラードメインに反映したいのはなぜですか？

— zrslv 2015

@zrxq確かにさまざまなエラードメインがあることには価値がありますが、プロジェクトのスペルを間違えたか、名前を変更してどこにでも反映させたいと想像してください。ハードコーディングするよりも動的に設定する方が良いです。

— コナー

@vareこれだけは明らかですが、実際にどのようなメリットが得られるかはよくわかりません。私の理解では、これらの識別子はアプリのコンテキストで一意である必要があるだけです。それだけです。さて、多分あなたはそれらをより審美的に喜ばせたいだけです、私はそれを手に入れました！

— zrslv 2015

ええ、あなたは良い点を持ち出します。ドメインを一意にしたい場合があります。たとえば、SDKまたは（cocoa）Podを作成している場合は、エラードメインにプロジェクトのドメインではなく、どこから来たのかを反映させたいと思います。名前。編集：私は（私の回答では）@ "com.myName.myProject"がこの場合のbundleIdentifierと同一であることを指摘したかったのですが、人々は知らないかもしれません。

— コナー

カスタムNSErrorを作成する方法：

まず、エラーメッセージの辞書を作成します

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

次に、userInfoをNSDictionaryに割り当て、完了します。

— マイク・ジエル
ソース