NSErrorを使用してエラーをチェックする正しい構造

Question

私はさまざまなルーチンをコーディングしています。私はそれをきちんとしてリファクタリングするよう全力を尽くしています。私が作成してい

方法は、このコードのようになり始めています：

-(IBAction)buttonPress:(id)sender { 
    // Create Document Shopping List with this document 
    [self doSomething:&error]; 

    if(error) { 
     [NSApp presentError:&error]; 
     return nil; 
    } 

    [self doSomethingElse:&error]; 

    if(error) { 
     [NSApp presentError:&error]; 
     return nil; 
    } 

    [self doYetSomethingElse:&error]; 

    if(error) { 
     [NSApp presentError:&error]; 
     return nil; 
    } 
} 

私はNSErrorを愛するが、これは私のすべてのエラーを処理するとても不器用なやり方のように思えます。

私は別の方法について持っていたいくつかの考え：

a）のエラーチェックがメソッドのdoSomething、doSomethingElseなどに組み込むことができ、その後私はせずにボタンを押す方法を終了することができないであろう戻り値について何らかのチェックをして、同様の構造に戻すことができます。

b）NSErrorをKey Value Observedとして設定することができましたが、これについて深刻な問題があると感じています。私はKVOとの虐待の可能性を非常に認識しているので、私は可能な限り無理なくすべてをやろうとしています。

本当にここで基本的なものが欠けていますか？私を助けることができるパターンがありますか？またはこの構造はOKですか？

Answer 1

私がここで提示した回答のどれも、アップルの推奨されている方法を考慮していないと思います。

基本的には、NSErrorオブジェクトをチェックして問題がないかどうかを確認しないでください。 NSErrorへのポインタへのポインタを取るメソッドから返された値をチェックすることによって、問題があるかどうかをチェックします。 the Apple documentationから

：

重要成功または失敗は メソッドの戻り値で示されています。 方法は、直接nilまたはNOを返すことで失敗したことを示している場合、間接的 にエラーオブジェクトを返すココア方法がココアのエラー・ドメインは、そのようなオブジェクトを返すことが保証されている、あなたは 常にnilまたはNO しようとする前に、戻り値があることを確認する必要がありますNSErrorオブジェクトを使用してください。

Answer 2

注：私がこれを投稿したとき、私はMacOS/Cocoaの例外の議論を知らなかった。この答えを考えているときは、このことを覚えておいてください。

代わりにexceptionsを使用しないのはなぜですか？これにより、メソッドのエラーパラメータを省略し、エラーを1か所で処理できます。

-(IBAction)buttonPress:(id)sender { 
    // Create Document Shopping List with this document 
    @try { 
     [self doSomething]; 
     [self doSomethingElse]; 
     [self doYetSomethingElse]; 
    } @catch (NSException* e) { 
     [NSApp presentException:e]; 
    } 
    return nil; 
} 

もちろん、あなたdoXXXX方法の中から必要に応じて例外をスローする必要があります。

NSException* e = [NSException exceptionWithName:@"MyException" 
             reason:@"Something bad happened" 
             userInfo:nil]; 
@throw e; 

Answer 3

私は本当の問題は、あなたのエラー処理に必要などのくらいの細かさだと思います。あなたのコードは根本的に正しいですが、頻繁にエラーをチェックしたり、NSExceptionで彼の答えに挙げられているteabotのようなキャッチオールの手法を使って、クリーンアップすることができます。 NSFileManagerのmoveItemAtPath :)のようなエラーを返す組み込み関数の多くは、NSErrorオブジェクトを提供することに加えてBOOLを返すので、NSError情報が必要ない場合は、ネストされたifステートメントを使用することもできます。

しかし、これを行うには本当に素晴らしい方法はありません。あなたのコードが長い場合、KVOはクールな解決策かもしれません。私はこのような状況でそれを試したことはありません。

Answer 4

質問の要点は、エラー処理に構造的な改善があるかどうかです。基本的には、より多くのコードを別々のメソッド/関数に抽出するか、高水準のサンプルメソッドにネストを導入することによって、より多くのネスティングレイヤーを導入することによって、そう考えています。

考えられるのは、ほとんどのエラーを処理する場合は、代替タスクを実行することに関心があるか、エラーの原因となってチェーンを上ってエラーを伝播して、責任あるコントローラがエラーをユーザーに伝えることができますUI。「伝播またはハンドル」のこのアイデアを使用して

、私はこのようなあなたのサンプルメソッドを書き換えます：特定の方法では、あまりにも多くのネスティングを導入に対する良好な引数があることを

-(IBAction)buttonPress:(id)sender { 

    // Create Document Shopping List with this document 
    [self doSomething:&error];  
    if(error == nil) { 
     [self doSomethingElse:&error]; 
     if (error == nil) { 
      [self doYetSomethingElse:&error]; 
     } 
    } 

    if(error) { 
     [NSApp presentError:&error]; 
    }  
} 

注意。このようなネストは、本質的にメソッドを抽出するための短い代替手段です。例えば「doSomething：」自体がdoSomethingElse：を呼び出すという意味で、doYetSomethingElseを呼び出します。これは、if-nestと同じ構造をコードに課しますが、間違いなくより保守性が高いでしょう。

脇に、私はインラインリターンステートメントのファンではありません。この特定の例では、サンプルメソッドは実際に戻り値を呼び出すのではありませんが、そうした場合は、返された値にローカル変数を設定し、フローコントロールの最後でのみ戻ります。関数やメソッドから早期に飛び出すことは、奇妙なバグIMHOに遭遇する確実な方法です。