サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
はじめにGoのエラー処理Goのエラー処理に何かライブラリを利用していますか？ この質問はGo 1.0のリリースから10年以上経つ今でも、日本のGoコミュニティでよくされる質問です。筆者（tenntenn）もよく他社の方からされます。 pkg/errorsやgolang.org/x/xerrorsがデファクトスタンダードだった頃と比べ、近年（2025年）はあまりデファクトスタンダードと呼べるライブラリが無いのが現状です。 また、言語仕様やerrorsパッケージについても徐々にアップデートされてきました。Go 1.13でエラーのラップやerrors.Is、errors.Asがリリースされ、pkg/errorsが作ったエラーをラップする文化が標準にも導入されました。同様にGo 1.20でerrors.Joinが入り、hashicorp/go-multierror やgo.uber.org/
unwrapではなく、expectで明示的にエラーが起こり得ない理由を示すというのも手なのかなと思っています。expectは「~であるべき」だったという旨を書くことが望ましいとされています。(Rustの公式ドキュメントのどこかに記載があったはずなのですが、探せませんでした。) panicは決して悪ではなく、開発者が想定していない状況に陥ったときの未定義動作を防ぐ最終防衛ラインとしての側面は大きいので、unwrapやexpectを使うなではなく、記事にある通り使ったときのメリットとリスクをきちんと天秤にかけることに尽きますね。
はじめにこんにちは！syumaiです。 久しぶりの投稿となりますが、2025年11月号として、9月上旬〜10月末頃に見かけて気になった、JavaScript/TypeScript（以下、JS/TS）、Go周辺の話題についてご紹介させていただきます！ まず、JS/TS関連の話題から紹介させていただくので、Goの話題が気になる方はページ下部の方からご覧ください！ JS/TSライブラリ・フレームワークHono CLIWebフレームワークのHonoが、なんとCLIツールをリリースしました。 このCLIツールは、Honoの使い方を調べたり、Honoアプリケーションのデバッグ、最適化などの機能を持っています。 なぜこのようなCLIツールをリリースしたのかというと、なんと、人だけではなくAIにも使ってもらうためとのことでした。 もちろん人が使っても便利なのですが、Honoの使い方を詳しく知らないコーディ
お試しで、Goのエラーハンドリングを省略するための try というライブラリを作っているので紹介します(最後にちょっとした告知があります)。github.com これを使うと、よくある iferr != nil を次のように記述できます。 // HandleとCheckは必ず同じスコープに書いて下さい cp,err := try.Handle() iferr != nil { // 下のCheckでエラーが発生したらここに飛ぶlog.Fatalln("Error:",err) } s := try.Check1(os.ReadFile("/tmp/xxx"))(cp) u := try.Check1(url.Parse(string(s)))(cp) fmt.Println(u.Path) try パッケージのAPIデザインはError Handling — Problem O
こんにちは、リアーキテクチャ＆イネーブルメント部のjunです。 普段はフレームワーク寄りの機能やライブラリの開発、パフォーマンスチューニング、リファクタリングなどなどプロダクトの土台を支える役割を担当しています。 今回は、運用品質向上のために開発した、Go言語のエラーハンドリングライブラリ「go-errorsx」の設計思想と活用方法をご紹介します。 ※go-errorsxはまだ発展段階のライブラリです。APIの変更や機能追加が行われる可能性があります。また、ValidationErrorは開発中の機能で、将来的にcontribとして別パッケージに分離する可能性があります。 なぜ新しいライブラリが必要だったのか 既存の素晴らしいGoエラーライブラリ（pkg/errors、eris、cockroachdb/errorsなど）はそれぞれ優れた特徴を持っていますが、運用品質を向上させる機能をもう
TheGoBlog [ On | No ] syntactic support forerror handling Robert Griesemer 3 June 2025 One of the oldest and most persistent complaints aboutGo concerns the verbosity oferror handling. We are all intimately (some may say painfully) familiar with this code pattern: x,err := call() iferr != nil { // handleerr } The test iferr != nil can be so pervasive thatit drowns out the rest of the cod
![[ On | No ] syntactic support for error handling - The Go Programming Language](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f61955b2029cca886435bd7bb93b949e8f18ae48d%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fgo.dev%252Fdoc%252Fgopher%252Frunningsquare.jpg&f=jpg&w=240)
エラー返値が無用な条件 関数ないしメソッドの実装がオンメモリ操作のみで完結 将来も（メモリ以外の）I/O操作は追加されることがない 逆にいうと上記の条件のいずれかが達成できない可能性がある関数やメソッドはエラー返値を付与すべき。 返値エラー型はerrorで統一する 返すエラーがerrorインターフェース型でなければそのエラーは正常にハンドリングできません。またerrorインターフェースを満たす別の返値型で返してerrorインターフェース型で受け取るのも後述のトラブルの元です。Goの実装方針に「インターフェースで利用するものもコンストラクター相当では構造体ポインタで返す」というものがありますがコンストラクタを呼ぶ側は元型にアクセスすることが多いのでこういう方針になっています。が、エラー値に関しては元型を意識せずに利用可能にするという役割があって、この実装方針は当てはまりません。 エラーチェ
Digitization部 Bill One Entry*1グループの秋山です。 はじめにDomain Modeling Made Functionalというスゴ本 補講：Make Illegal States Unrepresentable バックエンドの処理を抽象化する 手続き型プログラミングの典型例 課題1：制約のないエラーハンドリング 課題2：低い可読性 課題3：エラーハンドリングの低い網羅性 Railway OrientedProgrammingTypeScriptで型安全にエラーハンドリングする ステップ1：サブ関数の出力はResult型で表現する ステップ2：サブ関数にResult型を入力できるようにする ステップ3：サブ関数を連結する ステップ4：網羅的にエラーハンドリングする おわりに 付録TypeScriptの全文サンプル はじめに エラーハンドリングは重要な処
Twitterでこんな記事を見かけたので。zenn.dev ジェネリクスの件もそうですが、Goの言語設計は現実主義なのになにか特別なポリシーによるものだと宗教化されてしまって、ファンには勝手に崇拝されてアンチにはディスられがちだなーと感じます。Goのエラー処理を改善する実験プロジェクトxerrorsがGo本体のerrorsにマージされた時、errors.New() はスタックトレースを取得していました。しかしGo 1.13がリリースされる前に削除されました。 削除された理由の1つは、今までのerrors.New() のパフォーマンスに依存していたコードの速度が低下しアロケーションが増えることです。github.com しかし、これが理由だと今まで思ってたのですが、実際にはもう1つより重要な理由がありました。エラーのフォーマットです。エラーに複数のフォーマットを持たせようという提案
概要Go ではデフォルトのエラーに対して、自作エラーを作成して wrap するように有識者の間では推奨されています。 ただ、wrap すると本来のエラーが隠れてしまいテストや実行時に単純な比較ができなくなります。 そこで、よく紹介されるのが、errors.Isとerrors.Asです。erros.Isとerrors.Asを使うと wrap 済みエラーに対して、元のエラーとの比較できます。 しかし、紹介記事では、そのままコピー&ペーストするとtrueを返してほしいときに、falseを返してしまう方法を散見します。本記事では、間違えてしまうパターンについて紹介し、解決方法を紹介します。 元のエラーが不要で、wrap したエラーのみで比較する実装のときには、本記事の手順は不要になります。 うまく比較できないパターン 最初に、うまく比較できないパターンがどのようなときに発生するのか紹介します
H3ロケット初号機の打ち上げ取材で種子島へ行ってきた。残念ながら、打ち上げは中止になってしまい、初フライトを見届けることはできなかったのだが、記事はすでにマイナビニュースに4本掲載しているので、そちらをご覧になって欲しい。 2年間待たされた新型ロケットがいよいよ打ち上げへ、現地の最新状況は？ 機体移動前に打ち上げの延期が決定、最短で17日へ 機体移動が正常に完了、日本最大のロケットがついに姿を現す 異常を検知し打ち上げは中止に、エンジン起動から約6秒の間に何が起きた？ ところで2月17日、打ち上げ中止後の記者会見において、某社の記者が「失敗」か「中止」かで執拗に食い下がり、「それは一般には失敗と言います。ありがとうございます」と捨て台詞まで残したことが大きな話題となった。その後、SNS上でも批判や擁護の声が入り交じっていて収拾が付いていないようなので、専門のライターとして、改めて少し考えて
午後2時から行われた会見では、JAXAの岡田匡史氏（H3プロジェクトチームプロダクトマネージャ）が登壇し、経緯を説明。同氏によると、ロケットの自動カウントダウンシーケンスは予定通り開始され、メインエンジン「LE-9」が着火し正常に立ち上がったあと、ロケット下部（エンジン上部）に設置された1段制御用機器が異常を検知。SRB-3への着火信号を送らなかったことから、打ち上げ中止となった。なお、SRB-3側にも異常はなく、制御用機器が検知した異常そのものについては原因究明中という。 会見はJAXAの公式チャネルで配信されていたが、話題となったのが共同通信のとある記者の質問だ。「中止と失敗という問題についてもう一度確認したいです。ちょっともやもやするものですから」と切り出し、岡田氏に中止と失敗の違いについて質問した。以下はその一問一答だ。 共同 中止という言葉は、みなさんの業界でどう使われているかは
2006-07-28 近況 先週から体調が悪い. 体調が悪いときはまず本を読む. あまり疲れないもの, 新書や軽めのノンフィクション.技術書には手が伸びない. 手持ちの本が尽きると web を見てしまう. しかも "あとで読む" の消化などはしない. b.hatena.ne.jp などを上から眺めたり, 他人のアンテナなどを頼りに人気のあるページを見たり. ああ, 不毛だなあ... そんなかんじでうろうろしていたら, failmalloc というのを見けた. (作ったひとの日記.) 前の会社でも似たようなものを使っていたと思いだす. このごろ前職の話が多い気もするけれどまあいいや... failmalloc は malloc() を override して意図的にメモリ確保を失敗させるツールだ. メモリ確保エラーのチェック漏れをさがすのが狙い. 私の使っていたフレームワークも failm
errors, fmt: add support for wrapping multipleerrors ·golang/go@4a0a2b3 ·GitHub Anerror which implements an "Unwrap() []error" method wraps all the non-nilerrors in the returned ... https://github.com/golang/go/commit/4a0a2b33dfa3c99250efa222439f2c27d6780e4aGo でエラーを扱う際に、複数のエラーを束ねたい事があります。例えば複数のタスクを実行し、1つでもエラーになれば中断するのではなく、一通りタスクを実施し終えた結果を返したい様なニーズです。 package main import ( "errors" "log" "os"
Error messages should point toward a solution, not act as aBand-Aid. Image: denkcreative/GettyBy The concept ofembracing failure is big in thetech industry. “Fail fast, fail often” is almost an industry mantra. But there’s an everyday type of failure that doesn’t get much attention in the product development process: the humbleerror message. Theerror message should help the user solve the pro
Off-by-oneエラー（オフ-バイ-ワンエラー、off-by-oneerror、OBOE）とは、境界条件の判定に関するエラーの一種である。コンピュータプログラミングにおいて、ループが正しい回数より一回多く、または一回少なく実行された場合などに発生する。 この問題の代表的な原因として、プログラマーが数字のカウントを0からではなく1から開始してしまう（多くのプログラミング言語では配列の添え字は0から始まる）、数値の比較において「～未満」とすべきところを「～以下」としてしまう、等が挙げられる。また、数学的な処理を行っている場合にも発生しうる。 配列のm番目の要素からn番目までの要素を処理する場合を考える。処理対象の要素はいくつだろうか？この場合、直感的に考えるとn-m個となるが、実際には1個異なり、n-m+1個が正しい。これは「植え木算エラー」の一種である。 上記のような理由により、コンピ
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
Illustrationcreated for “A Journey WithGo”, made from the originalGoGopher,created by Renee French.Error management inGo is always prone to debate and a recurrenttopic in the annual survey about the biggest challenges developers are facing when usingGo. However, whenit comes to dealing witherrors in a concurrent environment or combining multipleerrors for the samegoroutine,Go provides
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
