はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth
データ取得で try...catch しない理由
try { const data = await fetchSomething(); // 正常系レスポンスの処理 } catch (err) { if (isAxiosError(err)) { // 異常系レスポンスの処理 } } 動機はつぎの 3 つです。 データ取得も宣言的に書きたいから データ取得に関係ない例外も catch してしまうから HttpError の集計に不便だから データ取得も宣言的に書きたいから 要約すると、データ取得時は常にこのように書きたい、という話です。useSWR・useQuery や apollo/client でお馴染みのインターフェイスです。 const { data, err, status } = await fetchSomething(); if (data) // 正常系レスポンスの処理 if (err) // 異常系レスポンスの処理
その例外、いつキャッチするの？
はじめに 最近、若手のコードレビューをしていて例外の使い方を教える機会があったので、ブログの方にもまとめたいと思います。今回はバッチ編。オンラインだとまた少し違う観点があると思います。また、言語はJavaを前提していますが考え方は例外機構をもつ言語ならあまり変わりません。 TL;DR 例外は原則キャッチしない。バッチは速やかに殺せ 個別箇所でログを出さずに必要な業務情報はExceptionを入れ子にして乗せる 長いバッチのためにはスキップもやむなし 原則、例外はキャッチしない JavaにはErrorとExceptionが存在し、OutOfMemoryErrorとかプログラム上ではどうしようもないものがエラー、ファイルが存在しない(FileNotFoundException)とかプログラム側でハンドリングするもの、と教科書では習うと思います。なのでException系はキャッチするものと、と
明日から使える実践エラーハンドリング
class: center, middle # 明日から使える<br/><strong>実践</strong><br/>エラーハンドリング Scala関西Summit 2018 11/10 --- class: left, middle ## 自己紹介 * 中村 学(Nakamura Manabu) * [@gakuzzzz](https://twitter.com/gakuzzzz) * Tech to Value 代表取締役 * Opt Technologies 技術顧問 <img src="../images/opt_logo_1.jpg" alt="Opt Technologies" width="450" style="margin-left: 0px" /> * F-CODE CTO <img src="../images/f-code_logo.png" alt="f-cod
【ソフトウェア設計】例外処理を考える
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？ 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
PySpa統合思念体です。あと、 @yosuke_furukawa にも協力いただきました。 基本的に、あまりエラーの種別を細かく判定してあげることはJavaScriptでは今までやってこなかったのですが、ちょっとしたメタデータを乗っけてあげるとか（例えばリトライ回数）、何か凝ったことをしたくなったらこういう方針でやればいいのでは、という試行錯誤録です。 エラーと例外の区別が必要か この手の話になると、エラーと例外の違いとか、こっちはハンドリングするもの、こっちはOSにそのまま流すものとかいろんな議論が出てきます。このエントリーではエラーも例外も差をつけずに、全部例外とひっくるめて説明します。 例外というのはすべて、何かしらのリカバリーを考える必要があります。 ちょっとしたネットワークのエラーなので、3回ぐらいはリトライしてみる 原因: ネットワークエラー リカバリー: リトライ サーバー
私がthrowを使わない理由
この記事について JavaScriptではthrow文という文を使うことで例外を投げることができます。 このthrow文ですが、私はレビューなどで例外を投げないでくださいというコメントをするのですがその理由とどのようにコードを変更すればよいのか、ということを書いておこうと思いました。 前提条件 この記事の内容は下記の条件を前提として書き進めていきます。 TypeScriptを採用していること フロントエンド開発の場合 Node.jsを利用したサーバーサイドのコードやCLIツールの開発、各種ライブラリの開発については本記事の対象に含まれないことをご了承下さい。 結論 先に結論から書いておくとTypeScriptを利用している場合例外はカスタムエラーを返却するか、Result型を利用するのがよいと思っています。 次の章からサンプルコードを用いながらthrow文を使った実例と、代替え案について記
はじめに アドベントカレンダー初参加です！ とある企業でサーバーサイドエンジニアとして働いており、主にGoでAPIを実装しています。 今年に入って新規事業の開発を任され、色々やらかしを経験させていただきました。 その中でも一番のやらかしを自戒の念も込めて投稿したいと思います。 特定を避けるために敢えて分かりづらく表現している箇所があります。その点ご了承くださいmm 惨劇発覚前夜 とある会員制サイトのリリースを控えており、それに備えて色々準備を整えてました。 リリース当日はそれなりにアクセス急増が見込まれるので ALBの暖気申請 フロントエンドサーバーのスケールアウト 等の対応を行いました。 今までも似たようなサイトをいくつかリリースしており、上記の対応でアクセスは捌けていたので今回も同様の対応で問題ないと思ってました。 リリース当日PM20:00 にサイトのURLを公開。 今までをはるかに
今月20日にInitial Releaseが予定されているNode.js v15ですが、ここでのunhandled rejectionの挙動変更について解説します。 unhandled rejectionとは async関数内でthrowされたエラーや、rejectされたPromiseが、.catch()などでハンドリングされずにrejectされたままになっている状態を、unhandled rejction（またはunhandled promise rejction）と呼びます。Node.js v14では、unhandled rejectionが発生すると次のような警告が出力されます。 $ node -e "Promise.reject()" (node:22145) UnhandledPromiseRejectionWarning: undefined (Use `node --trac
Result 型 (類似するものとして Either Monad の方が有名かもしれません) を導入する場合、アプリケーション全体の設計を変えたり、全箇所を書き換える必要はありません。 neverthrow は部分的に使用でき影響範囲も閉じるので、局所的に使い始めることができます。 (Rust のような) Result 型 とは ざっくり言うと関数の処理の結果と成否を 1 つの型 Result<T, E> で表したものです。(T は期待する結果の型、 E はエラーを表現する型) 筆者は詳しくはないのですが、 Haskell 等にある Either<L, R> とは厳密には違うようです(Either は両方の値が使用可能であることを前提としている？) 参考: Rust ではなぜ、Either 型ではなく Result 型を採用しているのか neverthrow とは TypeScript で
axiosの使い方まとめ (GET/POST/例外処理)
最近何かとよく使うJavaScriptでAJAX通信を行うaxiosについて、簡単に使い方をまとめました。 スポンサーリンク GETリクエストをaxiosで送る まずはGETリクエストをaxiosで送る方法です。 const res = await axios.get('/users') console.log(res.data) 分割代入の記法を使うと、以下のようにも書けます const {data} = await axios.get('/users') console.log(data) クエリパラメータ (URLパラメータ)を指定 クエリパラメータを指定する方法は2つあります。 1つ目は、axios.getに指定するURLに直接記述する方法です。 axios.get('/user?id=123') 2つめは、axios.getの第2引数に、オプション指定する方法です。 axios.
本記事は PowerShell Advent Calendar 2019 の 2 日目の記事です。 12月3日の0時を過ぎてから書いてます。すまん。 qiita.com 言わずもがなですが、PowerShell は処理の自動化を得意とした言語です。 そして、自動処理において、エラーへの対処は重要です。 何十万件というデータを処理してしまってから、実はエラーがあって、すべての処理結果が壊れているなんていうことになったら、目も当てられません。 ですから、（一般論としては）エラーが起きたら、可及的速やかに処理を中断し、報告すべきです。 別に何も目新しい話ではないのですが、自分でも時々「あれ、どうだったっけ？」と思うことがあるので、そのメモ書きです。 なお、以下、特記しない限り、PowerShell Core 6.2.3 + VSCode で検証しています。 中断されるエラーと中断されないエラー
はじめに 例外処理を実装するにあたって欠かせないのがtry-catch文です。これを使うことで、ランタイムエラーが発生しても処理を継続できたりするわけです。 ところでtry-catch文ではfinallyというものを使うこともできます。これはtryブロックの中が正常に完了しても、catchに進んだとしても、最後に実行される処理を書く場所です。 try { // 何らかの処理 console.log('tryで実行'); } catch { // エラー次の処理 console.log('catchで実行'); } finally { // 最後に必ず行う処理 console.log('最後に必ず実行'); }
Exceptions kind of suck in Haskell. You don’t get a stack trace. They don’t show up in the types of functions. They incorporate a subtyping mechanism that feels more like Java casting than typical Haskell programming. A partial solution to the problem is HasCallStack - that gives us a CallStack which gets attached to error calls. However, it only gets attached to error - so you can either have Str
C++の例外ハンドラを自作してみる。 - Qiita
となります。では、C++はどのように例外を実現しているのでしょうか。 例外、といっても実はいくつかの種類があります。Itanium ABIが定義した方法や、Sj/Ljと呼ばれる例外などです。また、OSなどの環境によっても異なってきます。 ここでは、Linux上のgccで使われている例外について解説します。環境はWindowsのWSL1上で、Linux環境は次の通りです。 $ gcc qiita_exception_workspace.cpp /tmp/cci042nX.o: In function `main': qiita_exception_workspace.cpp:(.text+0x19): undefined reference to `__cxa_allocate_exception' qiita_exception_workspace.cpp:(.text+0x2b): un
PowerShellでのエラー／例外処理についてにもうすこし突っ込んだことを書いたよ。（2018/11/30） PowerShellでtry～catchをしようとしても、うまくいかない、という事がある。 Cmdletが実行されたときに発生した問題（あえて例外とは書かないよ）は、コンソールに赤字で表示される（標準エラーではなさそう…）が、Cmdletを実行してるコンテキスト（例えば実装中のスクリプトとか）では例外としては扱われない1。 例外をキャッチする そんな時、-ErrorAction Stopをつけるか、$ErrorActionPreference="Stop"としておくと、Cmdletは例外を投げてくれる。 試す。 まず、以下だと例外投げてくれないので、赤文字が出る。 PS C:\Users\bounoki> try { Get-LocalUser nosuchuser } catc
PowerShell のコマンドレットは、エラー発生時に赤文字でエラーメッセージを表示します。 対話処理をしているときはこれで問題無いのですが、スクリプトでこれが発生した時に try catch でトラップしたいことがあります。 ところが、コマンドレットで発生するのはエラーであって、例外ではないため try catch ではトラップできません。 例えば、Rest API 叩くために Invoke-RestMethod 使って、エラーが帰ってきても赤色のエラーメッセージが表示されるだけです。 そんな時は、-ErrorAction オプションに Stop を指定すれば、エラー時に例外を throw してくれるので try catch でトラップできます。 例外発生時のメッセージは、$_.Exception.Message に格納されているので、これを使えばエラーメッセージをハンドリングすること
GitHub - dry-python/returns: Make your functions return something meaningful, typed, and safe!
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
エラー処理の基本の理解を深めよう！ - Qiita
throw文 エラーを投げるには、throw文を使用する！ throw文は、任意のタイミングでエラーを発生させるときに使用する！throw文でエラーを投げるためには、Errorプロトコルに準拠させる必要がる！ switch (response as? HTTPURLResponse)?.statusCode { case 200: let weatherData = try JSONDecoder().decode(WeatherData.self, from: data) let description = weatherData.weather[0].main let cityName = weatherData.name return (description, cityName) default: throw APIClientError.networkError } 上記はAPI
エラーハンドリングと監視
2021/6/27に発表した資料です。
はじめに 凄腕エンジニアさんから学んだ例外の話、たくさん読んでいただけているみたいでありがとうございます。 はてなブックマークのコメントなども読ませていただき、勉強させていただいています。 コメントを読んでみて、自分の記事がちょっと誤解を与えてしまっている部分もあるのかもしれない。。。と感じましたので、今回補足記事としてこの記事を書きます。 【例外が起こった時の挙動を決めるのはプレゼンテーション層】について この表現によって、例外は常にプレゼンテーション層でtry-catchをするものなんだと誤解を与えてしまったかもしれません。 この表現で伝えたかったこととしては、例外の挙動を決めるのは上位レイヤーであるため、下位レイヤーである業務ロジックの部分でtry-catchして例外が起こった時の挙動を決めるのはあまり良くないということでした。 システム例外と業務例外と区分したとして、Webアプリで
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
凄腕エンジニアさんから学んだ例外の話 - Qiita
JavaScript/TypeScriptの例外ハンドリング戦略を考える - Qiita
エラーハンドリングをミスって大事故に - Qiita
Node.js v15ではunhandled rejectionでプロセスがエラー終了する
neverthrow で局所的に Result 型を使い、 try-catch より安全に記述する
NTT、宇宙線による半導体ソフトエラー発生率の全貌解明。中性子による誤動作が対策可能に
PowerShell スクリプトのエラー処理の覚書 - 鷲ノ巣
try-catch のfinallyっていつ使うねん、ていう話 - Qiita
Dynamic Exception Reporting in Haskell
PowerShellで例外を捕まえられない - Qiita
例外を throw しない PowerShell コマンドレットを try catch でトラップする
【凄腕エンジニアさんから学んだ例外の話】の補足 - Qiita