データ取得で try...catch しない理由
2022/04/28 08:10
remonoil
fetchSomethingの中で必要なもの(リトライ、ロジック上のエラー等)だけやる派
2022/04/28 08:15
mayumayu_nimolove
これが最新版かな
2022/04/28 09:22
miki3k
通常発生するエラーは例外じゃないって考え方がしっくりくる
2022/04/28 09:46
shingo-sasaki-0529
HTTPのエラーとその他のエラーがごっちゃになるのわかる。axios もう一弾ラップして、宣言的に書けるようになるとカッコいいな。
2022/04/28 09:55
ryan_aircloset
わかるー。try catchするなら想定される例外はカスタムエラーであらかじめ定義しておいて、instanceOfで判定書いてあげると 予期したエラーか判断できるのでよき。ほんとは言語標準で提供してほしいけど。
2022/04/28 09:56
strawberryhunter
fetch()が例外を投げる理由が限定的なのでfetchSomething()の中で例外を投げるように書かなければcatchする理由もないのでは。
2022/04/28 10:13
poponponpon
APIだけ別会社が開発であんまり口出せない、、とかになると面倒くさいからとりあえずcatchしちゃっておくことはある
2022/04/28 10:14
maruware
rejectが例外になった弊害を感じる
2022/04/28 10:51
yarumato
“HttpError は開発者にとって想定範囲内だから。HttpError の集計(取得に全て成功/一部失敗)に不便だから。データ取得に関係ない例外も catch するから。データ取得ライブラリ風に宣言的に書きたいから”
2022/04/28 10:52
door-s-dev
あまりよく考えた記憶がない。適当になってそうなので後で確認する
2022/04/28 10:56
kako-jun
読ませてもらったよ……2、3疑問が残るが、刺激のある提案だ……と思った後、冬月じゃんって思った
2022/04/28 11:58
pwatermark
異常系含めて全部ハンドリングしてくれるミドルウェアであれば要らないんだけどね そうじゃないことも多いし
2022/04/28 12:05
ssids
HTTP GET ができないのは「異常(例外)ではない」って感じか。例えばブラウザ開いて読まなくて再読み込み押すなんて普通にスマホ使ってれば一日に一回ぐらいあるよね
2022/04/28 12:29
UhoNiceGuy
確かに致命的ではないエラーならtry…catchは大仰だね。モナドみたいに組み立てたくなる
2022/04/28 12:48
quality1
そうなの?わからんわ。
2022/04/28 12:57
tettekete37564
コードの浅い所、たとえばMVCのVやCでtry catchさせる思想のlibやFWや言語は本当にセンス無いと思う。ハード依存は仕方ないけどFWが依存してるlibの例外とか知らんがな。libのバグが原因のケースとかカバーしょうがない
2022/04/28 13:34
rryu
データ取得というかHTTPの200以外のレスポンスを例外で返さないという話。この手のライブラリをHTTPのステータスコードも使うREST APIで使うと地獄みが生じる。
2022/04/28 15:08
cubed-l
確かにレスポンスコードは並列で使いたい
2022/04/28 15:57
nilab
「データ取得ライブラリ風に宣言的に書きたいから」「データ取得に関係ない例外も catch してしまうから」「HttpError の集計に不便だから」
2022/04/28 18:48
pirila3849
then catchでプロミスでおk
2022/04/28 19:53
lunaphilia
Eitherがあればいい?
2022/04/28 19:56
hylom
個人的にはネットワークエラーは例外投げて、200以外のHTTPエラーコードは普通にresolveするべきだと思う(ブラウザのfetch APIやNodeのhttp.requestはそうなってる)、なのでtry〜catchはネットワークエラー対応のために書く
2022/04/28 21:11
eiki_okuma
ゲーム系だけどそもそもAPIがよくわからん例外を投げる時点で設計間違ってるので使わない
2022/04/28 23:37
da-yoshi
Try型がある言語の場合はそれを使ったりしてResponseの結果をまとめておくことが多いかな