タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
明日から使える実践エラーハンドリング
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
Goエラーハンドリング戦略
Goのエラーハンドリングが採ったスタイル 多値返し 直積（関数の返値とエラーを両方返す） try-finallyをdeferという機構でカバー panicはプロセスを落とすためのもの Goはこの戦略でエラーハンドリングを行うとしましたので、「多値はなぜタプルじゃないんだ？」、「直和（返値orエラー）で十分じゃ？」「panic-recoverでtry-catchできそう？」などいう様な他の処理系の風習を持ち込むことは意味がありません。そしてそれらの提案の多くはすでに検討されリジェクトされてきた経緯があります。 「try組み込み関数」プロポーザルなんかも検討されマージ直前くらいまで進んだこともありますが、「Goのエラーハンドリング」にとって一長一短がありました。その欠点課題は解決できずに最終的にリジェクトされました。 「多値返し」は実にCPUフレンドリーな機構で、C言語の関数呼び出し規約にちょ
Go のエラーハンドリング
私が Go のエラーハンドリングについて最初に記事にしたのは2015年のことだが，あれから Go も少しずつ変わってるし，私も当時よりは多少なりと理解が進んだと思うので，今まで書いた駄文を「全部入り」で本の形にしてみようと思う。 主な内容： * エラー評価の基本 * エラーの階層化 * サードパーティのパッケージ * ぼくがかんがえたさいきょうのえらーろぐ * Panic と Recover 寄付（サポート）歓迎。ご笑覧のほどを。
Goとエラーハンドリング慣習について
エラー返値が無用な条件 関数ないしメソッドの実装がオンメモリ操作のみで完結 将来も（メモリ以外の）I/O操作は追加されることがない 逆にいうと上記の条件のいずれかが達成できない可能性がある関数やメソッドはエラー返値を付与すべき。 返値エラー型はerrorで統一する 返すエラーがerrorインターフェース型でなければそのエラーは正常にハンドリングできません。またerrorインターフェースを満たす別の返値型で返してerrorインターフェース型で受け取るのも後述のトラブルの元です。 Goの実装方針に「インターフェースで利用するものもコンストラクター相当では構造体ポインタで返す」というものがありますがコンストラクタを呼ぶ側は元型にアクセスすることが多いのでこういう方針になっています。が、エラー値に関しては元型を意識せずに利用可能にするという役割があって、この実装方針は当てはまりません。 エラーチェ
TL;DR エラーハンドリングを行う目的 エラーハンドリングが適切に行われているとどう嬉しいか 1. エラーの発生原因が分かる 2. レスポンスステータスを型安全に出し分けることが可能になる どうエラーハンドリングを行うのか 実装方法 エラー型の定義で気を付けるべきポイント なぜanyhowを利用しないのか エラーハンドリングを行う上で持っている課題感 Drawer Growth グループ バックエンドエンジニアの中野です。今回は、私が所属するチームで gRPC API を開発する際に実践している Rust でのエラーハンドリングについて紹介していきます。 TL;DR エラーの発生原因がわかるようにエラー型を定義することが大切。 anyhow は使わずに自前のエラー型を定義して利用する。 エラーハンドリングを行う目的 そもそもなぜエラーハンドリングを行う必要があるのでしょうか。私が所属する
TypeScript開発にRailway Orientedを持ち込み、より型安全なエラーハンドリングへ - Sansan Tech Blog
Digitization部 Bill One Entry*1グループの秋山です。 はじめに Domain Modeling Made Functionalというスゴ本 補講：Make Illegal States Unrepresentable バックエンドの処理を抽象化する 手続き型プログラミングの典型例 課題1：制約のないエラーハンドリング 課題2：低い可読性 課題3：エラーハンドリングの低い網羅性 Railway Oriented Programming TypeScriptで型安全にエラーハンドリングする ステップ1：サブ関数の出力はResult型で表現する ステップ2：サブ関数にResult型を入力できるようにする ステップ3：サブ関数を連結する ステップ4：網羅的にエラーハンドリングする おわりに 付録 TypeScriptの全文サンプル はじめに エラーハンドリングは重要な処
こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしている高島（@takashima_katsu）です。 Gaudiyでは現在、BFFレイヤとしてGraphQLサーバを利用しています。導入してから1年以上が経ちますが、スキーマ駆動開発はDXの向上につながっていると実感しています。（以下のブログが詳しいです。） techblog.gaudiy.com 今回は、GraphQLの利点を活かしたエラーハンドリングの方法について、Gaudiyでの実践をもとに書いてみたいと思います。エラーハンドリングの実装について課題感のある人や、現在GraphQL Errorsを使っている人に、ぜひ読んでいただけると嬉しいです。 1. エラーハンドリングとGraphQL 2. GraphQL Errorsにおける課題 3. GraphQLエラーハンドリングの実践 3-
何番煎じかわかりませんが TypeScript でのエラーハンドリングについて考えてみたいと思います。 この記事で扱う TypeScript のバージョンは 4.3 です。 エラーを型安全に扱いたい TypeScript を書いていれば誰もが一度はぶつかる問題ではないでしょうか。 TypeScript では catch した例外は any として扱われます。 これは JavaScript の仕様上どんな値でも throw できてしまうため仕方のないことなのですが、せっかく型安全性を手に入れるために TypeScript を使っているのに any をハンドリングしなければならないのは苦痛です。 次のように例外を throw し得る関数 foo() のエラーハンドリングを考えてみます。 e は any なので、プロパティにアクセスしようにも危険性が伴います。 そこで型アノテーションを使用して
はじめに アドベントカレンダー初参加です！ とある企業でサーバーサイドエンジニアとして働いており、主にGoでAPIを実装しています。 今年に入って新規事業の開発を任され、色々やらかしを経験させていただきました。 その中でも一番のやらかしを自戒の念も込めて投稿したいと思います。 特定を避けるために敢えて分かりづらく表現している箇所があります。その点ご了承くださいmm 惨劇発覚前夜 とある会員制サイトのリリースを控えており、それに備えて色々準備を整えてました。 リリース当日はそれなりにアクセス急増が見込まれるので ALBの暖気申請 フロントエンドサーバーのスケールアウト 等の対応を行いました。 今までも似たようなサイトをいくつかリリースしており、上記の対応でアクセスは捌けていたので今回も同様の対応で問題ないと思ってました。 リリース当日PM20:00 にサイトのURLを公開。 今までをはるかに
Rustのエラーハンドリング関連の主要メソッドが一目でわかる、チートシートを作成しました。 Rustは型システムが複雑なので、やりたいことに適切なメソッドがあるかどうか、ドキュメントを探しまくることが多いです。エラーハンドリングもその類の1つであり、ドキュメント探索の手間を削減するために、チートシートを作成してみました。 ご活用ください。 1. チートシート 2. 関連リンク bool - doc.rust-lang.org Option - doc.rust-lang.org Result - doc.rust-lang.org
EC2のcronバッチを「EventBridgeをトリガーにStep Functionsを起動」に置き換えると、エラーハンドリングが快適になる
AWSのEC2で定期的なタスクを自動化するために、cronを使用しているケースも多いと思います。 しかし、Amazon Linux 2023ではcronがデフォルトで無効になっています。これはcron以外に、cronのようなバッチ実行・定期実行する仕組みがあるということなのかと思い、cronを使わずにE2上でバッチ実行・定期実行する仕組みを考えてみました。 そして、Amazon EventBridge、AWS Step Functions、およびAWS Systems Manager startAutomationExecutionを組み合わせて、EC2インスタンス上でバッチ・定期実行を試してみましたので、紹介します。 特に、Step Functionsを使用することで、エラーハンドリングや通知が容易になり、安全にバッチ実行できるようになります。 エラーハンドリングは以下の状態を把握したい
ActionMailerでのエラーハンドリングと、メール配信機能の冗長化 - ANDPAD Tech Blog
バックエンドエンジニアの宮澤です。 弊社のANDPADでは多くのWebサービスと同じようにメールでの通知機能を持っています。 今回はRailsと複数のメール配信サービスを組み合わせて、メール配信機能を冗長化した事例を紹介します。 ANDPADで導入しているメール配信サービス ANDPADでは2つのメール配信サービスを利用しています Mailgun（メイン） Sendgrid（サブ） 通常はMailgunを主系として利用し、SendgridはMailgunでの送信失敗時に備えて待機する構成になっていて、Mailgunで障害が発生した場合でも自動的にSendgird経由でメール配信できるようになっています。 また、サブにSendgridを採用している理由にRFCに準拠しないメールアドレスへの対策もあります。 ANDPADでは個人の携帯キャリアメールで登録しているアカウントも多く、キャリアメール
こんにちは、よしこです。 この記事では、わたしの所属する株式会社ナレッジワークで最近コードベースに取り入れた「エラーハンドリング漏れ防止の仕組み」について紹介します。 背景 「通信を伴うアクションに失敗しても画面にエラーフィードバックが表示されない」という実装漏れをしてしまったことがあり、今後こういうことが起きないように仕組みで防止したいと思いました。 「忘れてしまった」という問題なので、テストで担保するのも難しいように思いました。実装するのを忘れてしまっているということは、テストを書くこともセットで忘れてしまっているはずだからです。 「気をつける」「チェックリストを作る」のような人間が注意する方向ではなく、「嫌でも気付く」「忘れていたらCIが通らない」のように、必要なハンドリングを強制する形にできないか？と思いました。 課題 実行時に通信エラーが起きる可能性があり、ユーザーフィードバック
UbieにおけるGo言語のエラーハンドリング
背景 Ubieでは以下の記事にあるように、一昨年から新しく始めるプロジェクトにはGoとTypeScriptを積極的に採用しています。私は本来プロダクトセキュリティが主な専門領域なのですが、公私ともに普段からGoでツールやサービスの開発をしているため、社内のGo言語の普及をサポートしたりプロダクト開発に参加したりしています。 Go言語で開発したことがある方はご存知かと思いますが、Goは標準パッケージで提供されているエラーハンドリングは最低限の機能しか提供されていません。これは、CLIツールなどではエラーの内容が簡潔に表せてよいのですが、サーバサイドアプリケーションのようにエラーにまつわる情報を詳細に残してあとから調査に利用する、という場面では不向きです。特に本番環境でしか再現しないようなエラーの場合は、いかに関連情報を残せているかが、問題の解決に大きく影響します。 先日も話題になっていました
「フロントエンドLT会 - vol.8」で発表したスライドです。 https://rakus.connpass.com/event/255095/
ユースケース層が投げうるエラーの型を「量化した open union」にしておけば複数のユースケースを合成したときに上の層でエラーハンドリングが楽にできて最高です！ - ryota-ka's blog
この記事は以下のページに移転しました． blog.ryota-ka.me この記事は Haskell Advent Calendar 2020 20日目の記事です． TL; DR タイトル 問題設定 ユースケース層とサーバ層が存在する Web アプリケーションを考える．サーバ層はユースケース層を呼び出すことができるが，ユースケース層はサーバ層について無知でなければならない． +----------------+ | server layer | +-------+--------+ | depends on +-------v--------+ | use case layer | +----------------+ このようなアプリケーションのAPI リクエストハンドラにおいて，複数のユースケースを合成して呼び出すケースを例に挙げ，それぞれのユースケースが投げうるエラーをうまく扱う o
gRPC × Go × Node.js におけるエラーハンドリングの実現方法 - Gaudiy Tech Blog
この記事は「Gaudiy Advent Calendar 2022」の19日目の記事です。 Web3 スタートアップの Gaudiy でソフトウェアエンジニアをしている Namiki ( @ruwatana ) です 🙂 ワールドカップを楽しみすぎていたら（日本代表もそして数時間前の決勝戦も本当に最高でした 🙌）、あっという間に自分の番が来てしまったわけですが、先月個人にフォーカスした 入社エントリ を書かせていただいたのもあり、今回は直近取り組んでいた gRPC周りのエラーハンドリングで得た技術的なナレッジ を共有できればと思います。 みなさんエモさ全開の記事を書いているところ、ただ実直にTechでコアな話をしていきます。 ちなみに弊社 Tech Blog への寄稿は初となりますので、お手柔らかにお願いします。誤ったことを書いていましたらこそっとご指摘いただけますと幸いです 🙇 1
2021年7月現在、goでエラーハンドリングってどうやって扱うのが無難なのかについて、いろいろと調べました。 昔から人気な pkg/errors、Go公式がメンテナンスしていたxerrors、 go v1.13から追加されたfmt.Errorfなどエラーハンドリングの選択肢がいろいろとあるので、stacktrace欲しい場合とそうでない場合で個人的にベストだと思った方法をまとめました。 エラーハンドリングに求める要件 エラーが発生した箇所を追える エラーの原因によって処理を分岐する （場合による）stacktraceがみれる 結論 stacktraceが不要な場合 fmt.Errorfでラップし、errors.Isで判定する stacktraceが必要な場合 pkg/errors.Wrapでラップし、pkg/errors.Causeで判定する log.Printf("%+v", err)で
最近 ChatGPT API にコードを書かせてそれを eval するという仕組みを作りました。 その際に考えたエラーハンドリングのプラクティスが、ChatGPT API ならではで個人的に面白かったので記事に残しておきます。 📝 tl;dr ChatGPT はコードを書くことを拒否する場合がある。考慮したリトライの仕組みを作る ChatGPT の書いたコードで発生したエラーは ChatGPT に解決してもらう 💬 何をやろうとした？ 以前の記事にて Minecraft 上で ChatGPT に作りたいものを伝えると魔法みたいに実現してくれるコマンドというものを紹介しました。 豪華(?)な家を作ってもらう例 このコマンドの実装はとてもシンプルで、ユーザーの指示（prompt）から ChatGPT API にコードを書かせて、それを eval しているだけです。 def think_co
エラーハンドリングを少しずつ改善していく / improving error handling little by little
エラーハンドリングを少しずつ改善していく / improving error handling little by little
Swiftがオープンソースになって以来、長年議論され続けてきたTyped throwsの提案がついに承認されました。これは、throws節にエラー型を指定できる新しい言語機能であり、Swift 6から導入されます。 Swiftにおけるエラーハンドリングの考え方は、Swift 2でthrows/tr…
タクシー車載機は長時間稼働を前提にバッテリーレスに 須田桂伍氏（以下、須田）：株式会社ソラコムのSAをやっております。須田と申します。 私はSAをやっているんですが、プロフェッショナルサービスというかたちで実際にお客様の案件に入って一緒にモノを作ったりコードを書いたりしているので、その辺の経験を踏まえて何かお話できたらなと思います。 僕は社会インフラ系をやっていて、例えば某ガス事業会社さんで改善したりとか、あとは普通に生きていれば出会うことはないと思いますが、石油プラントって爆発しちゃうので火気厳禁じゃないですか。そういうところで使うようなデバイスをどう作ったらいいか、ということを一緒にやったりしています。こんな感じです。 司会者：ありがとうございます。それではSli.doに来ていた質問を私の手元でいくつか集計をして質問をまわしていきたいなと思っています。 では最初に、JapanTaxiさ
この記事は GraphQL Advent Calendar 2020 6日目の記事です。 前回の記事は @fossamagna さんの AppSyncのGraphQL APIを@apollo/clientで呼び出す でした。 この記事では以下の記事で紹介されているGraphQLのエラーハンドリングの手法についての紹介と、それを利用するクライアントサイドのメリットについての考察をしていきます。 sachee.medium.com アプリケーションで生じる様々なエラーと、GraphQLの一般的なハンドリング GraphQLはリクエストに対してエラーが発生した場合、一般的にレスポンス中のerrorsというキーの中にそのエラーに関する情報を詰め込んだレスポンスを返すというプラクティスがあります。 "errors": [ { "message": "....", "locations": [ ...
Goでのオススメエラーハンドリング手法
この記事は「Eureka Advent Calendar 2020」の19日目の記事です。 こんにちは、2020年今年こそはとダイエットに意気込み、振り返ってみればジムへ行ったのは1回きり、出前を頼んだのは100回以上、見事に5kg体重を増やした山下です。 昨日は同じBackendチームのJamesさんによる「Understanding Allocations in Go」でした。 今回はこちらの記事にあるPairsエンゲージのエラー機構を詳しく説明していきたいと思います。 （本当は面白Goクイズをたくさん出したかったのですが、playgroundをmedium上にうまく埋め込めず断念しました。泣） 概要errorsパッケージを作成して独自のエラー構造体を定義しましょうエラーは全ての箇所でラップして綺麗にスタックトレースを出力しましょうエラーレベルやエラーメッセージを付与して汎用性を高めて
【アップデート】ストリームベースで起動するLambdaのエラーハンドリングがやりやすくなったよ！ | DevelopersIO
先日こんなアップデートがありました。 AWS Lambda Supports Failure-Handling Features for Kinesis and DynamoDB Event Sources KinesisやDynamoDBのストリーム型のイベントソースで起動するLambdaが失敗した際の挙動をカスタマイズできるようになったみたいです。 アナウンスはAWS re:Invent 2019より前でしたが、重要なアップデートなので試してみたいと思います。 なにが変わったのか？ LambdaのトリガーにKinesisを選択すると、選択項目が追加されていました。 「障害時の送信先」 レコードの有効期限切れもしくは再試行で失敗した際に、SNSかSQSにレコードを送信できるようになったようです。非同期LambdaのDLQと同じような機能ですね。 「再試行」 失敗した際のリトライ回数を設定
非同期呼び出しAWS Lambdaのエラーハンドリング機能を整理してみた(宛先指定・経過時間・試行回数・DLQ) | DevelopersIO
関数を用意 入力イベントをそのまま返すだけの Lambda 関数を用意します。 def lambda_handler(event, context): return event 設定方法 Lambda 関数の宛先を選択し、成功・失敗のステータスに応じてターゲットを選択するだけです。 成功・失敗のステータスごとに指定できるターゲットは一つだけです。 ターゲットを SNS か EventBridge にしておくと、将来の Fan Out がかんたんになります。 今回は 成功・失敗それぞれに対して専用の SNS トピックを用意し、JSON-Email で受け取るようにしました。 実行例 Lambda 関数を非同期に呼び出します。 $ aws lambda invoke --function-name test \ --invocation-type Event \ --payload '{"fo
PHPerKaigi2022 に登壇し、「PHPのエラーを理解して適切なエラーハンドリングを学ぼう」というタイトルでお話ししました！ - 弁護士ドットコム株式会社 Creators’ blog
こんにちは、弁護士ドットコムでエンジニアをやっている @namizatork です。 今回は、弊社もTシャツスポンサーとして協賛している PHPerKaigi2022 に登壇し、「PHPのエラーを理解して適切なエラーハンドリングを学ぼう」というタイトルでお話ししました！ PHPerKaigi2022 4/9(土) 20:15 ~ 20:35 Track A speakerdeck.com 今回の PHPerKaigi では、すべてのセッションが事前の録画収録になっていました。普段、僕は登壇1日前に徹夜して資料を仕上げるので、いつも他のセッションを見る余裕がないのですが、今回は心にゆとりを持って当日を迎えることできました！（いつも事前に仕上げろ） 今回は、せっかくなので day0（前夜祭） にオフライン会場で自分の録画収録を見てきましたが、自分の録画した姿をみんなに見られてるのは結構恥ずかし
PowerShell はエラー処理がとても難しい言語として知られています。 きちんと理解しようとすると途端に深みにハマってしまいます。 それこれもエラーの挙動が正しくドキュメント化されていないことが原因なのですが。 そこで、今度こそ PowerShell のエラーをきちんと理解しようといろいろ調べました。 結果としてまだまだ腑に落ちない箇所がありつつも、一定程度は理解できたような気がしましたのでここにまとめておきたいと思います。 おことわり 本記事は PowerShell の中の人である Michael Klement 氏がこちらのGitHub Issueにコメントしている内容を基に、筆者の独自検証の結果やそれに基づく解釈を加えています PowerShell の実際の挙動を把握することに重点を置いているため、公式ドキュメントに記載のない内容や独自の用語を記載・使用しています 内容の正確性は
最近は1からGoでサービスを開発する機会があり、その際にGo1.13から追加された新機能を導入して使ってみたりしています。 例えばerrorsパッケージのAs関数やIs関数などです。 https://golang.org/pkg/errors/ 上記のerrorsパッケージはエラーハンドリングを実装する際によく利用しています。 本記事ではerrorsパッケージを使った効果的なエラーハンドリング実装についてまとめます。 記事の構成は最初にエラーハンドリングの設計で目指す要件を簡単に説明したあと、 その要件を満たすようなシンプルなWebアプリケーションの実装を提示します。 実装するエラーハンドリングの設計について 本記事で示すアプリケーションのコードでは、下記の項目を満たすようなエラーハンドリングを実装していきます。 エラーの発生箇所がログから確認できる 発生したエラーの原因を推測するためにコ
この記事は NSSOL Advent Calendar 2022 の1日目の記事です はじめに 私が現在所属しているチームでは、フロントエンドもバックエンドも共にTypeScriptをで開発を進めており、具体的にはフロントエンドではReact、バックエンドではNestJSを使用しています。 TypeScriptで共通化させることで、TypeScriptが提供する型安全性を享受しながらも、バックエンドとフロントエンドで大きなコンテキストスイッチを発生させることなく開発を進めることができていると感じています。 ただ、実感としては、バックエンドではソフトウェアで解決したい対象となるドメインのモデルを class で表現したり、フロントエンドのReactでは小さい関数や hooks を集約させることでロジックを表現したりと、フロントエンドとバックエンドでのロジックの構築方法に差異を感じていました。
この記事について GRPC は HTTP/2 の上に構築されているため、クライアントからサーバーのサービス呼び出しや、サーバーからクライアントへ戻り値やエラーの送信、といったやり取りは HTTP/2 のリクエストとレスポンスで実装されています(もうちょっと厳密に言うと HTTP/2 フレームを使って実装されている)。 この記事ではGo言語のGRPC実装(grpc-go)を用いて、以下についてまとめてみました。 GRPC が用いる HTTP/2 のリクエスト、レスポンスの流れと構造 その中でエラーがどう伝播されるか GRPC の Unary RPC のエラーハンドリング 扱いにちょっと悩む Streaming RPC のエラーハンドリング 環境等の情報 記事の作成に用いた環境: Go言語 : v1.15.6 grpc-go : v1.34.0 この記事で用いたソースコード grpc-erro
はじめに｜Go のエラーハンドリング
【JS / TS】非同期通信（axios）ごとにtry~catchを実装したくない人のためのエラーハンドリング Tips💡
投稿する背景 初めての投稿となりますので、お手柔らかにご一読していただけると何よりです🙌 なぜ、今回重い腰を上げて本記事を執筆することにしたかと言うと、ある時、非同期通信処理（axios）を挟むごとに無意識でtry~catchを実装していた自分に疑問を抱いたからです。🤔 （進撃の巨人で言うと、「無意識に壁の外に人類が存在しない」という当たり前のように思っていたことから、真実に差し迫ったエルビン・スミスみたいな感じです。アニメ派なので執筆時点では最終回はまだ見ていません🙈） try~catchを何度も実装せずにエラーをハンドリングできるインターフェースを持った関数を実装したら、どれだけ楽になるか、そう模索した結果、辿り着いた実装を共有したいと思います👀 対象読者 非同期処理ごとに「try~catch〜」を書かなければいけない習慣に疲れた人😩 try~catchにおけるエラーハンドリ
Promise でのエラーハンドリング
promise チェーンはエラーハンドリングに優れています。promise が reject されると、制御は最も近い reject ハンドラに移ります。この動きは実際に非常に便利です。 例えば、下のコードでは URL が誤っており(存在しないサイト)、.catch がエラーをハンドリングします: fetch('https://no-such-server.blabla') // rejects .then(response => response.json()) .catch(err => alert(err)) // TypeError: failed to fetch (エラーメッセージ内容は異なる場合があります) ご覧の通り、.catch は直後である必要はありません。1つまたは複数の .then の後に現れるかもしれません。 また、サイトはすべて問題ありませんが、レスポンスが有効
サーバーレスアプリケーション開発におけるエラーハンドリング ~ ワークフローパターン 前編 ~ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
選択 第 1 回 オープニング 第 2 回 Web API パターン 第 3 回 イベント駆動のデータ加工、連携処理パターン 第 4 回 マイクロバッチ・ストリーミングパターン 第 5 回 ワークフローパターン 前編 第 6 回 ワークフローパターン 後編 ワークフローパターンは、条件分岐を含むシーケンシャンルなステップの集合です。それらのハンドリングを一つのプログラムモジュールで実現しようとすると、条件判断や、エラーハンドリング、リトライ、などのビジネスロジック外の本質的ではないコードが多く記述されることになり、また単一のモジュールにすべての処理をまとめると、各々の処理が密結合になるリスクなどもあります。 こういったリスクを排除するために、ワークフローエンジンを利用し、各処理単位で独立したタスクに切り出したプログラムモジュールを組み合わせて、本質的ではないタスク間の連携処理については、ワ
failureでお手軽エラーハンドリング
failureでお手軽エラーハンドリング 2024/04/23 Goのエラーハンドリング 最新事情Lunch LT morikuni
サーバーレスアプリケーション開発におけるエラーハンドリング - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
選択 第 1 回 オープニング 第 2 回 Web API パターン 第 3 回 イベント駆動のデータ加工、連携処理パターン 第 4 回 マイクロバッチ・ストリーミングパターン 第 5 回 ワークフローパターン 前編 第 6 回 ワークフローパターン 後編 みなさん ! サーバーレスアプリケーションの開発楽しんでますか ? サーバーレスアプリケーションの開発は、インフラ面での非機能要件の責任を AWS のマネージド型サービスに委譲できることから、アプリケーションの本質 である ”ロジック開発" に注⼒できる点が私は大好きです ! 機能を実装していくプロセスは、明確にやりたいことに向かって進んでいくこともあり、成果がわかりやすく非常に楽しいですよね。 しかしサーバーレスアプリケーション開発は実現したいロジックの実装に集中できるからといって、正常系の実装の検討しか行わずに、サービスをリリースし
Rails で例外を発生させたい際は，raise...つまり RuntimeError をよく使用するかと思います。 しかし，サービス上の制約から，特定の状況下で例外を発生させる場合，raiseだけでは物足りなくなる時があります。 raiseでは「何かまずいことが起きてしまいました！」程度のことしか伝えてくれません。まぁ，引数に渡す message を見れば理解できるかもですが... 兎にも角にも，特定の状況下に対する例外が存在するなら，その例外に対して名前を付けてあげましょう。 カスタム例外を設定すると，発生時に「何に対する例外か」がパッと理解できるようになりますし，特定の動作に誘導することも容易になりますので，良いことづくめです！ 参考 URL 等 項目22 | Effective Ruby（長尾高弘 arton PeterJ.Jones）｜翔泳社の本 Railsアプリケーションにおけ
この記事は Go4 Advent Calendar 2019 7日目の記事です。 2016年にGoのAdvent Calendarを書いた時はGo3までだったのに、今年はGo7まであり、Go言語の盛り上がりを感じます。 以前書いたGo言語のエラーハンドリングの記事がじわじわと反響をいただいており、とても嬉しく思います。 上の記事を書いた当時は趣味でGo言語を嗜んでいた程度ですが、ここ1年は仕事でGoの開発に関わり、エラーハンドリングとロギングの重要性を思い知らされた次第です。自分では適切なエラーハンドリングやロギングをしたつもりでも、いざリリースしてみるとログが不足していて調査に手間取ったり、逆に過剰で精査に時間がかかったり… 本記事はここ1年Goで書いたプログラムを運用してみて得た知見を記事に起こしたものです。 TL;DR エラーはWrapしつつ適切なメッセージを付与して返すといいよ！
Express公式サイトのベストプラクティスには、パフォーマンスと信頼性についてのベストプラクティスが解説されています。 その中で、適切なエラーハンドリングのベストプラクティスについて解説されています。 Express（Node.js）では発生したエラーがキャッチされないと、プロセスが異常終了したりハングしてしまいます。そうなると、Epxressアプリケーションの信頼性（可用性）が地に落ちてしまいます。このようにエラーハンドリングの適切さは信頼性に大きく影響するため、エラーハンドリングはとっても重要なのです。 今回の投稿では、Express公式サイト（と、そこからリンクされる参考ページ）で紹介されているエラーハンドリングのベストプラクティスを、できるだけ分かりやすく説明させていだこうと思います。 まずはアンチパターンについて説明します。 Expressにおけるエラーハンドリング【アンチパタ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RustでWeb APIを作る際のエラーハンドリング - CADDi Tech Blog
GraphQLにおけるエラーハンドリングの実践 - Gaudiy Tech Blog
TypeScript のエラーハンドリングを考える - Qiita
エラーハンドリングをミスって大事故に - Qiita
Rustエラーハンドリング・チートシート - Qiita
Result型とESLintでエラーハンドリング漏れを検出する
ReactのSuspenseを使った非同期処理のエラーハンドリング
今goのエラーハンドリングを無難にしておく方法（2021.09現在）
ChatGPT API にコードを書かせて eval する際のエラーハンドリング・プラクティス
Swift 6のTyped throwsとSwiftにおけるエラーハンドリングの全体像を学ぶ
ハードウェアのエラーハンドリング、どうやってる？ 4社のエンジニアが語る、IoTサービスづくりの工夫
クエリ結果を軸としたGraphQLのエラーハンドリング - indilog
PowerShell のエラーハンドリングを（今度こそ）理解する - Qiita
【Go】errorsパッケージを使ってエラーハンドリングをうまくやる - Qiita
TypeScriptでResult型でのエラーハンドリングを通してモナドの世界を覗いてみる - Qiita
GRPCのリクエスト構造とエラーハンドリング - Qiita
Rails によるカスタム例外の設定とエラーハンドリング - Qiita
運用を意識したGo言語でのエラーハンドリング/ロギング - Qiita
Expressでのエラーハンドリング ベストプラクティス - Qiita
news.tv-asahi.co.jp
english-dic.jp
l.smartnews.com
helentech.jp
x.com
blog.livedoor.jp/kuubohosiina