このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしている高島（@takashima_katsu）です。 Gaudiyでは現在、BFFレイヤとしてGraphQLサーバを利用しています。導入してから1年以上が経ちますが、スキーマ駆動開発はDXの向上につながっていると実感しています。（以下のブログが詳しいです。） techblog.gaudiy.com 今回は、GraphQLの利点を活かしたエラーハンドリングの方法について、Gaudiyでの実践をもとに書いてみたいと思います。エラーハンドリングの実装について課題感のある人や、現在GraphQL Errorsを使っている人に、ぜひ読んでいただけると嬉しいです。 1. エラーハンドリングとGraphQL 2. GraphQL Errorsにおける課題 3. GraphQLエラーハンドリングの実践 3-
この記事は GraphQL Advent Calendar 2020 6日目の記事です。 前回の記事は @fossamagna さんの AppSyncのGraphQL APIを@apollo/clientで呼び出す でした。 この記事では以下の記事で紹介されているGraphQLのエラーハンドリングの手法についての紹介と、それを利用するクライアントサイドのメリットについての考察をしていきます。 sachee.medium.com アプリケーションで生じる様々なエラーと、GraphQLの一般的なハンドリング GraphQLはリクエストに対してエラーが発生した場合、一般的にレスポンス中のerrorsというキーの中にそのエラーに関する情報を詰め込んだレスポンスを返すというプラクティスがあります。 "errors": [ { "message": "....", "locations": [ ...
Error handlingHow gRPC deals with errors, and gRPC error codes. Standard error modelAs you’ll have seen in our concepts document and examples, when a gRPC call completes successfully the server returns an OK status to the client (depending on the language the OK status may or may not be directly used in your code). But what happens if the call isn’t successful? If an error occurs, gRPC returns one
概要TIG DX所属の多賀です。最近は設計をしつつ Go も触れて引き続き楽しく仕事してます。 今回は、errors package を一部利用して、エラーコードベースのエラーハンドリング処理を実装しました。また、morikuni/failure を利用した実装への書き換えも試してみています。 エラーコードベースの例外ハンドリングについて前提としてGoで書かれた HTTP APIサーバーに対してのエラーハンドリングについて記載します。 エラーコードベースの例外ハンドリングについてですが、アプリケーションで発生するエラーを事前にラベリングしてコード化し、コードをもとにエラーハンドリングを実施することとします。発生時の運用対応や影響について、事前に一覧で整理することで、運用負荷を下げる意味があると考えています。(補足: Futureではメッセージコードと呼称することが多いですが、一般的な命名で
やっぱり自分なりにまとめないと理解した気になれないので、まとめてみることにする。 https://godoc.org/github.com/pkg/errors Golangにおけるエラー処理(おさらい) Goは言語仕様として例外機構(Exception)がない。例外ではなく、複数の戻り値を返せるという特徴を利用し、最後の戻り値をエラーに割り当てるということをする。throwを書きたくなったら代わりにreturnを書くわけだ。 import "fmt" // helloはnameが空だったらエラー扱いにする func hello(name string) (string, error) { if name == "" { return nil, fmt.Errorf("name is invalid") } return fmt.Sprint("hello %v", name) }
GoConでは毎回エラー処理について面白い知見が得られる．Go Conference 2014 autumn においては（実際のトークではないが）居酒屋にて@JxckさんがRob Pike氏から以下のようなテクニックを紹介してもらっていた． Errors are values - The Go Blog Golang Error Handling lesson by Rob Pike これはWrite（やRead）のエラー処理が複数続く場合にerrWriter を定義して複数のエラー処理を一箇所にまとめてコードをすっきりとさせるテクニックであった． そして今回の Go Conference 2016 spring のkeynoteにおいてもDave Cheney氏から（僕にとっては）新たなエラー処理テクニックが紹介された． Gocon Spring 2016 実際に使ってみて/コードを読ん
panicwrap is a Go library that re-executes a Go binary and monitors stderr output from the binary for a panic. When it finds a panic, it executes a user-defined handler function. Stdout, stderr, stdin, signals, and exit codes continue to work as normal, making the existence of panicwrap mostly invisible to the end user until a panic actually occurs. Since a panic is truly a bug in the program mean
NOTE: この記事は Inspecting Errors を翻訳したものです。 原文に従い、 Creative Commons ライセンスで公開します。 error インターフェイス型の値を返す関数の一般的な契約は、呼び出し側はその error をチェックする前にそれ以外のいかなる戻り値も利用してはいけないというものです。 多くのケースにおいて、関数が返した error 値は呼び出し元にとって不透明であるべきです。 error が nil かどうかチェックすることで呼び出しが成功したかどうかを知ることができ、そしてそれ以上のことはしません。 少ないケースにおいて、主にネットワークなどプロセス外の世界とやりとりする場合に、呼び出し側がエラーの種別を調べて、操作をリトライするべきかどうかを決める必要があります。 パッケージ作者に対して、呼び出し側がエラーの型を判別して利用できるように返すエラ
The common contract for functions which return a value of the interface type error, is the caller should not presume anything about the state of the other values returned from that call without first checking the error. In the majority of cases, error values returned from functions should be opaque to the caller. That is to say, a test that error is nil indicates if the call succeeded or failed, a
Intro この記事は Go Advent Calendar 2014 の 15 日目の記事です。 例えばネットワークのフレーム処理的なものを書いている場合、以下のようなコードがよくでてきます。 There are many codes like this, while writing a Network Frame Parser program. var type uint8 err = binary.Read(r, binary.BigEndian, &type) if err != nil { return err } var length uint32 err = binary.Read(r, binary.BigEndian, &length) if err != nil { return err } ... 関数の中では、各要素の長さ毎に読み込んで、読み込みに失敗したらエラーを
errwrap is a package for Go that formalizes the pattern of wrapping errors and checking if an error contains another error. There is a common pattern in Go of taking a returned error value and then wrapping it (such as with fmt.Errorf) before returning it. The problem with this pattern is that you completely lose the original error structure. Arguably the correct approach is that you should make a
Goを書いていてrecoverを使うことはまずほとんどない。頻繁にrecoverを書いているとしたらなにかが間違っているのでプログラミングスタイルを見直すこと。 Goでのエラーハンドリング Effective Goなどで説明されているように、Goではエラーは関数の返り値として返される。たとえばio.ReaderのRead関数は、読み込んだバイト数と、（nilかもしれない）エラーの2つの値を返す。Goでは基本的に、エラーは常にこういう通常の値としてハンドルするべきで、エラーの時のための特別な制御構造（try 〜 catch）のようなものを使うのは、利点より害のほうが多いという考え方をとっている。 （同じような考えで例外を使用禁止にしている大規模C++プログラムはいくつもある。たとえばChromiumなどはそうだ。LLVM/Clangもパフォーマンス上の問題で例外を使っていない。C++コンパイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
