(Error)非同期エラー処理とページルーティング

1. 🕹 細部は本当に重要です

開発の過程で、いろいろな要素を考慮しますが、その中で最もテクニックが必要な部分はエラー処理だと思います.
何の考えもない場合には,単純な機能を実現することを目的とした開発が第一歩と考えられる.もちろん、それ自体も優秀ですが、完璧ではありません.いつでも起こり得るエラーを適切に処理する能力は非常に重要ですが、実際にはそれは難しいです.難しいですね.多くの知識や経験を積んでこそ、「このまま進めば、間違いの可能性がある」と本能的に予見できるからだ.
従って、これらの困難を解決するために、通常は簡単なtry~catchを用いてエラー制御を行う.
この方法は気持ちがいい.

try{
 //... 무언가를 실행하다가 여기서 에러를 발생시킨다면 자동 "throw Error객체" 를 실행해주기 때문
}catch(err){
 // try 블록 안에서 발생한 에러는 자동으로 catch의 인자로 전달된다.
}

その利点は、上のように包むだけでエンジンが自分で処理されるので、あまり複雑に考えなくてもいいということです.
しかし、この快適さに慣れると、昨日開発したときに出会った間違いが多くの例外に遭遇します.

2. 🕹 非同期操作で失効したtry~catch

tryに存在するエラー内容はcatchブロックに自動的に渡されます.
しかし、catchブロックに渡されるのは「同期操作」に限られることが重要である.
もしかすると、便利な方法でasync awaitを書くと、このような問題に遭遇しないかもしれません.
async文が存在する関数ブロックで実行される待機文は非同期操作であるが、「同期」処理の完了を待つためである.

async function test (){
   try{
       await somethingAysnc() // 해당 비동기 작업이 완료되어 Promise 객체의 state 슬롯에 들어오기까지 기다려준다.
   }catch(err){
        console.log(err) // 위 작업에서 에러가 나면 catch가 이것을 캐치한다.
   }
}

しかし、問題は、様々な理由でasync waitが使用できないことです.
昨日の携帯ケースと同じようにtypescriptを使っていましたが、cachstorageの2番目のパラメータが伝達されるタイプは無条件応答タイプなのでaxiosを使っていましたが、タイプエラーが多すぎて修理してしまったので、タイプライターを打つのが面倒で長すぎたのでfetchを直接使いました.

すでに写真で結論が出ていますが、fetchを使用する場合、最外周のtry~catchではそのfetch操作の誤りを捉えられません.
これはfetchが非常に簡単であるため、fetchは非同期操作であるため、関数呼び出し時に実行コンテキストの内容が上から下へ順次行われ、非同期処理はWeb APIに渡され、task queueに登録され、呼び出しが空になるまでアクセスして実行される.

function test (){
   try{
      fetch()..... // 해당 구문은 비동기 작업이므로 자바스크립트 엔진 입장에선 그냥 web API에 던져주고 넘어가버린다.
   }catch(err){
        console.log(err) // 따라서, catch로 전달되는 것도 없고, 이 함수 호출이 끝난 후 뒤늦게 fetch가 콜스텍에 들어가 실행되어 에러뿜뿜
   }
}

すなわち,非同期動作を考慮せずにtry~catchに入れると,エラー処理は全く行われない.従ってcatchメソッドをスクリーンに接続して処理する必要がある.
その後、catch、finallyのようなフィルタリング方法は、chromewal、microtechnologyと呼ばれる特殊な材料構造に入り、非同期Promise処理時に、対応する[promiseResult]スロットの結果に基づいて、そのフィルタリング方法に関連付けられたmicrotechnologyを巡回し、適切な方法を見つけて呼び出す.エラーの場合、catch構文が見つからない場合は、windowに登録されている最後のunhandlediscountsイベントリスナーを検索します.ここにコンテンツが存在しない場合、エラーが発生し、プロセスが死亡します.

window.addEventListener('unhandledrejection', function(event) {
  // 이벤트엔 두 개의 특별 프로퍼티가 있습니다.
  alert(event.promise); // [object Promise] - 에러를 생성하는 프라미스
  alert(event.reason); // Error: 에러 발생! - 처리하지 못한 에러 객체
});

new Promise(function() {
  throw new Error("에러 발생!");
}); // 에러 처리 핸들러, catch가 없음

3. 🕹 履歴エラー

この分野は普段何気ないところで、いきなり開発中に発見されました.
たとえば、あるページに入ると、Redux storeに存在するデータに基づいてページが表示されるとします.
ユーザーがリフレッシュ時にreduxstore内部データに対して適切な措置を取らなかった場合(ex、キャッシュなど)
更新すると、ショップは初期化され、ページ内でこのデータに基づいてUIを実装してもデータがないため、エラーが発生し、プロセスが死亡します.
それ以外に、ページがルーティングによって移動し、後退などの操作に必要なデータがなければ、エラーが発生し、プロセスが死亡することもあります.
すなわち,このような状況に対応するためには,ユーザが履歴スタックを用いてアクセスする行為に適切な措置をとる必要がある.
実際、最初は履歴を初期化できると思っていたので、安易にチェックしようと決心しましたが、セキュリティ面では履歴自体を削除する機能は追加されていません.
従って、特定のredox storeデータが必要なページであれば、条件付きでリダイレクト処理を行う.

// KeywordPage.js

  useEffect(() => {
    if (!selector.searchList.length && !localStorage.getItem("searchState")) {
      navigate("/");
    }
  }, [navigate, selector]);

/// UrlPage.js

  useEffect(() => {
    if (!selector.searchTarget && !localStorage.getItem("searchState")) {
      navigate("/");
    }
  }, [navigate, selector]);

これにより,特定のページにおいて,ある条件を満たさなければ,直接ページに入ることができる.

// Home.js

 useEffect(() => {
    //if comming back
    dispatch(reset());
    localStorage.removeItem("searchState");
  }, [dispatch]);

ホームにアクセスした瞬間、初期Reduxに存在する検索記録データを初期化する.
このように設定すると、後退ボタンに戻ろうとするとuserEffectが実行され、ホームページにリダイレクトするよう求められます.
すべてのページに対してこのような例外処理を行うのは容易ではありませんが、より細かいアプリケーションを実現するために必要な条件だと思います.