Java ライブラリを Objective-C に変換しています。Java コードは例外を目に余るように使用します (Objective-C に慣れている私の考えでは)。変換するとき、Objective-C 例外をスローする必要がありますか (ライブラリ内のみ。例外が終了する前にキャッチします)、または NSError コンストラクトを使用する必要があります。
私は通常の Objective-C コードでの例外のユースケースに精通しています。つまり、真に例外的なエラーの場合のみです。ここで決定的な答えが得られない場合は、おそらく NSErrors を使用します。
Objective-Cで例外をスローしてキャッチするのはコストがかかります（@try例外キャッチコードの一部が一部ではなく高価な部分である32ビットMac OS Xを除く@catch）。
NSErrorいくつかのメカニズム（ Objective-Cでそれを行うOOの方法など）でエラーコードを返す方が良いでしょう。それらをフレームワークにアクセスするコードにバブルアップさせてから、そのコードに適切に処理させます。
ほとんどのオブジェクトと割り当てを自動解放プールに入れることができるはずなので、どちらのシステムでもエラーが発生した場合のメモリのクリーンアップは大きな心配にはなりません。ただし、プールはそのスコープ内で作成されたオブジェクトをすべて消費NSErrorするNSExceptionため、これらのオブジェクトが追加の保持とリリースを使用してコードの最後を超えて存続することを確認する必要があることに注意してください。（少し話題から外れていますが、エラー処理を行うときに多くの人がこの部分を台無しにするのを見てきました。）
ライブラリがすべての例外を単独で処理できる場合、それらは実際には Objective-C の意味での例外ではありません。プログラマ エラーは発生していません。むしろ、完全に予期されていたことが起こったのです。必要に応じてエラーコード/を使用するNSError必要がありますが、例外によって提供される情報の多くを破棄して、「エラー」を示す値 ( nil、0、およびNSNotFound一般的なもの) を返すことができる場合があります。それを処理します。エラー処理デリゲート メソッドを検討することもできます。
Objective-C ライブラリ (NSError アプローチ) でエラーを返すだけです。結局のところ、これはCで行われるエラー処理の方法です。
例外を使用するかどうかについてはあまり心配しません。コードがきれいになる場合は、それらを使用してください。あなたが本当に注意しなければならない唯一のことは、あなたが書いていないほとんどすべてのコードである例外セーフであるとあなたが知らないコードを通して例外をスローしないことです.
はい、例外を使用するとコストがかかりますが、それについて心配することは時期尚早の最適化の例です。結局のところ、C 関数呼び出しと比較して、Objective-C メッセージのディスパッチはコストがかかりますが、Objective-C プログラマーが「Objective-C メッセージを使用しないでください」と言っているのを耳にすることはありません。