Q&A
Entity Framework 6 の接続の復元機能というのがありますが、そういうのは使えないですか？
現在作っているツールが、通信が不安定な状況で使用されることになります。
具体的に言うと、建物内でノートパソコンを持ち歩いて好きな場所で使う為にWifiを使っており、
その建物が7階建の鉄筋コンクリートだからです。
一般的な有線LANの屋内ネットワークをただ無線にしただけという状況をイメージして頂いて構いません。
その環境で、ユーザーがデータ送信/受信した後、「ハンドルされていない例外」だけは避けたいのです。
ユーザーによって実行される全ての通信処理部分に例外処理を入れるとかなりの量になる為、通信以外起因の例外処理と合わせると、
自分のスキル的にも作業量的にもカバーしきれない気がしています。
ですので、今考えている方法は、
①3～5秒おきに建物内サーバー・ルーター・外部IP(8.8.8.8)等に送信し、応答の有無で、実行ボタンの有効/無効を切り替える。
②使用頻度が高い(たまたま通信不調なのにボタンが有効な間にクリックされる可能性が高そうな)ボタンの処理は例外処理を加える。
という方法なのですが、これは妥当なのでしょうか？
普通はどうするのでしょうか？
> 通信が不安定な環境で使用するツールを作る場合の鉄則的なものを教えてください
不安定かどうかに関係なく、通信エラーを含めエラーの場合を振る舞いを実装するのが鉄則です。
> 普通はどうするのでしょうか？
普通などというものは無く、アプリの性質で対応は変わってくるので設計次第です。
（受信がメインなのか、送信がメインなのか、はたまた両方か、どの程度リアルタイム制が要求されるか等）
受信がメインなら、通信状態がいい時に事前にバックグラウンドでデータを読ませて保持しておく等が出来ますね。
無線側のハードや配置変更で通信環境自体を改善出来るなら、そちらの方が楽かもしれません。
普通はデータアクセス層を作って、そこで想定できるエラーをハンドリングする
かな？
回答2件
0
「ハンドルされていない例外」だけは避けたい
その言葉をそのまま要件とするなら「ハンドルしましょう」という結論にしかなりませんが、まずそれは理解してるんでしょうか。
ユーザーによって実行される全ての通信処理部分に例外処理を入れるとかなりの量になる為、通信以外起因の例外処理と合わせると、
自分のスキル的にも作業量的にもカバーしきれない気がしています。
通信が発生する最も下のレイヤで例外処理ができないのであれば、より上位レイヤで補足して処理するしかないという話。通信エラー由来の例外の種類を予め特定しておき、その特定例外をキャッチして適切に処理しましょう。
ただし、上位レイヤで補足した例外ほどリトライなどの復旧ロジックの構築は困難になるんで、例外を補足した時点で取れる選択肢はユーザーに単純に失敗を通知するだけ、というケースが大半になると思いますけど、それは問題ないんでしょうか？
ですので、今考えている方法は、
①3～5秒おきに建物内サーバー・ルーター・外部IP(8.8.8.8)等に送信し、応答の有無で、実行ボタンの有効/無効を切り替える。
②使用頻度が高い(たまたま通信不調なのにボタンが有効な間にクリックされる可能性が高そうな)ボタンの処理は例外処理を加える。
という方法なのですが、これは妥当なのでしょうか？
妥当かどうかはあなたの求める要件に依存するんで他人が判断することはできません。
①はタイミング依存なんで論理的に問題を解決できてないし、②は使用頻度が低ければ無視して良いのか、というのは他人にわかるはずもないし。
今回は通信が不安定なことを懸念しての話なんで、例外発生場所に近い場所でPollyなどのライブラリを使えば簡単にリトライを実装できるため、本来そうするべきだと思いますけど、どうしてもそれができないなら上位レイヤで「通信の発生しうるすべての場所」でハンドルしてエラーメッセージを出す、ってのが妥協点じゃないんでしょうか。
投稿2021/07/07 23:29
編集2021/07/08 01:20
総合スコア8947
そもそも使用頻度とそのアプリにとってクリティカルな操作か否かは無関係なんで、使用頻度が高いから処理する、という②の発想は根本的に問題があります。
仕様として重要度をちゃんと判断してるのならまだ理解できますけど。
0
という方法なのですが、これは妥当なのでしょうか？
とにもかくにもそれで実装して動かしてみましょう。
それで大丈夫ならそれが正義ですし、それでダメなら組み直しするということになります
投稿2021/07/07 23:06
総合スコア88042
あなたの回答
tips
プレビュー
