7

私は現在、クロスプラットフォームのモバイルアプリ開発において非常に重要な岐路に立たされており、実際にいくつかの専門知識を使用することができます (woah など)。

いくつかのコンテキストを提供するために（私が望む答えに役立つかもしれません）、VS2010U（MonoDevelopではなく、まだIOS用）を使用して、便利なMonoCrossフレームワークに基づいて.NETでモバイルアプリを開発しています。最初に対象となるプラットフォームは Android で、次に IOS と Windows Phone の「ポート」に移行します (私が正しくやった場合はそうではありません)。

ビジネス ロジック、データ アクセス レイヤー、データベース、REST Web サービスなどを含む堅固な基盤が整ったので、いくつかのエラー処理を実行しようとしていますが、これに対する最善のアプローチが何であるかはわかりません。は。

try-catch ブロックはパフォーマンスに影響を与える可能性があると言われましたが (この場合は大問題です)、
これは本当ですか? それらを控えめに使用するか、例外がスローされる可能性のある場所ならどこでも平手打ちする必要があります（半分の時間で一体何をしているのかわからないので、すべてのSQLite API呼び出しでそれらを使用したいと思います）。

エラー処理にイベントコールバックを使用するのは悪いことですか? パフォーマンス上の理由から、try-catch とは対照的に、可能な限りこれらを使用するようにアドバイスされましたが、設計の原則やパラダイムを壊して、ずさんなコードをいたるところに配置したくありません。

3 番目のオプションは、オーバーヘッドが最も少ないですが、対処するのが非常に面倒です。これは、ステータス フィールドと戻り値です。

それで、あなたたちはどう思いますか？私は、いくつかの一般的な方向性と、それぞれをいつどこで使用するかについてのいくつかの提案、および私が省略した可能性が最も高い他のテクニックを探していると思います。詳細が必要な場合はお知らせください。喜んでお知らせします。

このたびはお時間を割いていただき、ありがとうございました。

4

4 に答える 4

4

あなたのプログラムを醜くしたのは、優れた例外処理パターンが整っているにもかかわらず、どこでも例外処理を行っているためだと思います。

コードベース全体で発生するこの種の機能は、ロギング、セキュリティ、監査、例外処理などのクロスカッティングコンサーンと呼ばれます....

http://msdn.microsoft.com/en-us/library/ee658105.aspx#ExceptionManagementで適切なパターンを見つけることができます。

Microsoft docs で推奨されているように EntLib を使用することはお勧めしません。

アスペクト指向プログラミング (AOP) を探すと、良いリソースが見つかります。そして最後のヒントは、実装が依存性注入/IoC フレームワークを使用してこれらの問題に対処することです。

于 2012-07-03T19:54:11.987 に答える
2

半分の時間で何をしているのかわからないので、すべての SQLite API 呼び出しでそれらを使用したいと思います。

SQLite とのインターフェイスにライブラリを使用していると言っている場合、このライブラリ API が特定のエラー ケースで既に例外をスローしている可能性があります。もちろん、このような場合は、これらの呼び出しの前後で try/catch を使用して、これらの誤った状況を処理する必要があります。

これは、そのコードを自分で書いていない場合や、他の人のライブラリを使用している場合に常に当てはまります。

これらのエラーをどのように処理するかは、あなたの決定です。

私のアドバイス:

  • ほとんどの場合、私はコールバック/イベントに反対しています。これらは主に、エラーが発生する API が非同期であり、そのためにプログラム フローがすでに自明ではない場合に使用する必要があります。
  • 例外のスローは、ステータス コード/戻り値よりも確かに遅くなりますが、アプリがタイム クリティカルではない状況では、現在のモバイル プラットフォームで安全に使用できます。モバイルゲームは例外スローを使用しており、 (一種の) タイムクリティカルです。
  • 例外をスローすると、コードの可読性が向上します。私の意見では、これは主観的なものであり、エラーが発生した場合に現在のコンテキストから飛び出す良い方法です。
于 2012-07-03T20:18:37.457 に答える
1

理論が特定の実装と一致しない場合もありますが、Mono にはこれらの概念がしばらくの間存在していたと思います。

適切なランタイムは、例外のない場合のパフォーマンスを常に優先します。理想的には、例外がスローされない場合、try/catch ブロックは、try ブロックの内容が単独で実行されたかのように実行され、try/finally ブロックは、try ブロックと finally ブロックの内容が実行されたかのように実行される必要があります。順に実行。CIL バイトコード インタープリターを使用する場合、通常、ここで述べたようなオーバーヘッドなしでこれらの操作を実行することはできません。ただし、適切な JIT または AOT コンパイラ (Mono で得られるようなもの) は、例外のない場合でも、try/catch/finally 構造を省略した場合と同じくらい高速に実行されるコードを実際に生成します。¹

代わりにエラー コードの戦略を選択すると、エラーが発生していなくても、アプリケーションはエラー処理コードの一部を実行することになります (メソッドに余分なパラメーターを渡したり、リターン コードを計算してテストしたりするなど)。したがって、あなたの目標は、例外処理の使用を真に例外的なケースに制限することです。この戦略は、パフォーマンスが重要な成功事例のパフォーマンスを低下させることなく、堅牢なアプリケーション (適切なエラー処理) につながります。

¹ 数値計算ループの本体に組み込まれた try/finally ブロックの場合、これは 100% 正確ではありませんが、例外的なケースを処理するために適切に使用された場合に、パフォーマンスに目に見える影響を与える可能性は、現時点では事実上ゼロです。具体的には、X86 用にコンパイルされた try/finally ブロック JIT には、try/finally ブロックのない同じメソッドと比較して、push/pop/jmp (ローカル ブランチ) 命令に似たコードが含まれます。これは、次のように定義されたメソッドへの呼び出しよりもオーバーヘッドが少なくなります。public static void Foo() {}

于 2012-07-03T20:34:32.170 に答える
1

予想される例外をキャッチしtry/catchたい場合は incase を使用してください。通常、例外によってワークフローを決定するのは適切な選択ではありませんが、IO 操作の場合はこれが唯一の選択肢になる可能性があります。たとえば、突然接続が失われた外部デバイスに書き込みます。この場合、プログラムは例外を受け取りますが、通常のエラーのように処理する必要があります。

于 2012-07-03T19:44:52.000 に答える