記事へのコメント23

    • 注目コメント
    • 新着コメント
    ryosuke-fujii
    ryosuke-fujii const { data, err, status } = await fetchSomething(); こういうふうに書きたいねという記事。

    2023/05/18 リンク

    その他
    da-yoshi
    da-yoshi Try型がある言語の場合はそれを使ったりしてResponseの結果をまとめておくことが多いかな

    2022/04/28 リンク

    その他
    eiki_okuma
    eiki_okuma ゲーム系だけどそもそもAPIがよくわからん例外を投げる時点で設計間違ってるので使わない

    2022/04/28 リンク

    その他
    hylom
    hylom 個人的にはネットワークエラーは例外投げて、200以外のHTTPエラーコードは普通にresolveするべきだと思う(ブラウザのfetch APIやNodeのhttp.requestはそうなってる)、なのでtry〜catchはネットワークエラー対応のために書く

    2022/04/28 リンク

    その他
    nilab
    nilab 「データ取得ライブラリ風に宣言的に書きたいから」「データ取得に関係ない例外も catch してしまうから」「HttpError の集計に不便だから」

    2022/04/28 リンク

    その他
    cubed-l
    cubed-l 確かにレスポンスコードは並列で使いたい

    2022/04/28 リンク

    その他
    rryu
    rryu データ取得というかHTTPの200以外のレスポンスを例外で返さないという話。この手のライブラリをHTTPのステータスコードも使うREST APIで使うと地獄みが生じる。

    2022/04/28 リンク

    その他
    tettekete37564
    tettekete37564 コードの浅い所、たとえばMVCのVやCでtry catchさせる思想のlibやFWや言語は本当にセンス無いと思う。ハード依存は仕方ないけどFWが依存してるlibの例外とか知らんがな。libのバグが原因のケースとかカバーしょうがない

    2022/04/28 リンク

    その他
    quality1
    quality1 そうなの?わからんわ。

    2022/04/28 リンク

    その他
    UhoNiceGuy
    UhoNiceGuy 確かに致命的ではないエラーならtry…catchは大仰だね。モナドみたいに組み立てたくなる

    2022/04/28 リンク

    その他
    ssids
    ssids HTTP GET ができないのは「異常(例外)ではない」って感じか。例えばブラウザ開いて読まなくて再読み込み押すなんて普通にスマホ使ってれば一日に一回ぐらいあるよね

    2022/04/28 リンク

    その他
    pwatermark
    pwatermark 異常系含めて全部ハンドリングしてくれるミドルウェアであれば要らないんだけどね そうじゃないことも多いし

    2022/04/28 リンク

    その他
    kako-jun
    kako-jun 読ませてもらったよ……2、3疑問が残るが、刺激のある提案だ……と思った後、冬月じゃんって思った

    2022/04/28 リンク

    その他
    door-s-dev
    door-s-dev あまりよく考えた記憶がない。適当になってそうなので後で確認する

    2022/04/28 リンク

    その他
    yarumato
    yarumato “HttpError は開発者にとって想定範囲内だから。HttpError の集計(取得に全て成功/一部失敗)に不便だから。データ取得に関係ない例外も catch するから。データ取得ライブラリ風に宣言的に書きたいから”

    2022/04/28 リンク

    その他
    maruware
    maruware rejectが例外になった弊害を感じる

    2022/04/28 リンク

    その他
    poponponpon
    poponponpon APIだけ別会社が開発であんまり口出せない、、とかになると面倒くさいからとりあえずcatchしちゃっておくことはある

    2022/04/28 リンク

    その他
    strawberryhunter
    strawberryhunter fetch()が例外を投げる理由が限定的なのでfetchSomething()の中で例外を投げるように書かなければcatchする理由もないのでは。

    2022/04/28 リンク

    その他
    ryan_aircloset
    ryan_aircloset わかるー。try catchするなら想定される例外はカスタムエラーであらかじめ定義しておいて、instanceOfで判定書いてあげると 予期したエラーか判断できるのでよき。ほんとは言語標準で提供してほしいけど。

    2022/04/28 リンク

    その他
    shingo-sasaki-0529
    shingo-sasaki-0529 HTTPのエラーとその他のエラーがごっちゃになるのわかる。axios もう一弾ラップして、宣言的に書けるようになるとカッコいいな。

    2022/04/28 リンク

    その他
    miki3k
    miki3k 通常発生するエラーは例外じゃないって考え方がしっくりくる

    2022/04/28 リンク

    その他
    mayumayu_nimolove
    mayumayu_nimolove これが最新版かな

    2022/04/28 リンク

    その他
    remonoil
    remonoil fetchSomethingの中で必要なもの(リトライ、ロジック上のエラー等)だけやる派

    2022/04/28 リンク

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック!
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

    データ取得で try...catch しない理由

    try { const data = await fetchSomething(); // 正常系レスポンスの処理 } catch (err) { if (isAxiosE...

    ブックマークしたユーザー

    • noguful2023/12/25 noguful
    • takaesu2023/12/21 takaesu
    • mjclab2023/10/02 mjclab
    • ryosuke-fujii2023/05/18 ryosuke-fujii
    • techtech05212023/02/14 techtech0521
    • chibahiro2023/01/24 chibahiro
    • syukit2022/09/27 syukit
    • zakiy2022/09/26 zakiy
    • nobyu2022/09/25 nobyu
    • onigra2022/05/16 onigra
    • kjkj_ongr2022/05/11 kjkj_ongr
    • J1382022/05/09 J138
    • marutaku01312022/05/05 marutaku0131
    • rinrinbell2022/05/02 rinrinbell
    • ohchang2022/05/02 ohchang
    • k_hamada_19882022/05/01 k_hamada_1988
    • enokawaa2022/04/29 enokawaa
    • zaki10102022/04/29 zaki1010
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事