プログラミングにおける例外戦略の鉄則はありますか？ - Quora例外を握りつぶさないDBトランザクションの場合はちゃんとロールバックするログを残す基本的にデータベースや外部APIとの通信部分にしか張りません。 自分の書いたコードで例外が必要になるのはおかしいからです。 データベースの場合、データの整合性が取れていない マスターデータが流される場合があるので検知用に仕込んでいます。 外部のAPIも同様で、相手側がなにかミスした場合を立証するのに役立ちます。
JavaScript/TypeScriptの例外ハンドリング戦略を考える - Qiita
PySpa統合思念体です。あと、 @yosuke_furukawa にも協力いただきました。 基本的に、あまりエラーの種別を細かく判定してあげることはJavaScriptでは今までやってこなかったのですが、ちょっとしたメタデータを乗っけてあげるとか（例えばリトライ回数）、何か凝ったことをしたくなったらこういう方針でやればいいのでは、という試行錯誤録です。 エラーと例外の区別が必要か この手の話になると、エラーと例外の違いとか、こっちはハンドリングするもの、こっちはOSにそのまま流すものとかいろんな議論が出てきます。このエントリーではエラーも例外も差をつけずに、全部例外とひっくるめて説明します。 例外というのはすべて、何かしらのリカバリーを考える必要があります。 ちょっとしたネットワークのエラーなので、3回ぐらいはリトライしてみる 原因: ネットワークエラー リカバリー: リトライ サーバー
例外、エラー、異常、そして - Qiita
「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 本来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected
使い捨てのコードのエラー処理について - podhmo's diary
tl;dr panic時ではなくerror時にもfullのstack traceが欲しい pkg/errors が便利 はじめに しばらくgoを書いていて、使い捨てのコードのエラー処理についてどうすれば良いのか考えたりしていた。ここで言う使い捨てのコードというのは1ファイル位で作れそうな小さなコマンドラインのコマンドのようなものを指している。 まともなアプリケーションコードでは考えることが色々ある気がするけれど。使い捨てのコードなら以下を満たしていれば十分だと思った。 終了ステータスが0以外になる エラーの発生箇所が正確に分かる(stack trace) 前者はテキトーに書いても自然に満たす気がする。ここでは後者をどうするかについて書く。 panic時は問題なし。ただしerror時には問題がある ここでいうエラー処理は以下の２つを含んでいる。 panic時の処理 error時の処理 テキト
JavaScriptエンジニアなら知ってるよね？ エラー処理のいい書き方、悪い書き方
JavaScriptのエラー処理、ちゃんと書いていますか？ エラーを無視せず、どこに問題があるのか、きちんと確認できるコードの書き方をデモで紹介。 この記事はTim SeverienとMoritz Krögerが査読を担当しています。最良の記事を提供することができ、SitePointの査読担当者の皆さんに感謝します。 JavaScriptのエラー処理には危険が潜んでことを知っていますか？ もしマーフィーの法則を信頼しているとしたら、不具合が生じる可能性が本当に高いです！ この記事では、JavaScriptのエラー処理について考え、その落とし穴から便利な実践例までを説明します。さらに最後には、非同期コードとAjaxにも触れます。 JavaScriptはイベント駆動型プログラムで、プログラミングをより豊かなものにしてくれます。ブラウザーをイベント駆動型プログラムと考えると、発生するエラーは同一
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
例外処理とロギングのベストプラクティス
はじめに システム開発において例外処理は重要なポイントですが、あまりに軽視されているのが現状ではないでしょうか。本稿では、これまでの著者の開発経験の中から培った汎用的な手法を説明します。 この記事は「美しい設計」ではなく「現実的な設計」、現場に適用できる「できるだけ手間の少なく、汎用的な設計」を目指しています。 対象読者 J2EE開発者・アーキテクト。特に業務システムの開発現場の方が対象です。 必要な環境 概念の説明が中心ですので、開発環境は必要ありません。 エラーの分類 実装時に考慮すべきエラーは2つに大別できます。 想定内でトランザクションの実行開始前にチェックするエラー。主に入力エラー。 異常な状態としてトランザクションの続行が不可能なエラー（例外）。 前者については、例外を使うべきではありません。入力チェックエラーを表現するには、ステータスコードを使うべきです。理由は次のとおりです
python デコレータを使って例外処理をモジュール化する - fakatatuku’s blog
pythonで普通に例外処理を書くと、以下のようになる。 def hoge(*args): try: # 処理 except Exception as e: # 例外処理 return def fuga(*args): try: # 処理 except Exception as e: # 例外処理 return def piyo(*args): try: # 処理 except Exception as e: # 例外処理 return 例外処理の内容が全て同じである場合（例えばログに吐き出すとか）、かなり冗長である。 そこでデコレータを使用すると以下のように書ける。 def exception(func): def wrapper(*args, **kwargs): try: return func(*args, **kwargs) except Exception as e: # 例外
Java/Androidにおける例外設計、あるいは「契約による設計」によるシンプルさの追求 - Qiita
なぜ今Javaの例外処理か Javaにおける「チェック例外」はSwift、Objective-C、Ruby、JavaScriptといったネイティブ・ウェブアプリ開発でよく用いられる他の言語には現れないものです。 SwiftにはOptionalやErrorTypeがありますが、Javaにおいてもnullやエラーのハンドリングの実装方法をうまくやる必要があります。 なぜ例外を握りつぶしたらいけないのか、なぜアサーションが望ましいのか、なぜチェック例外と非チェックを分けたのか、という点を考えてみたいと思います。 参考資料 例外設計における大罪 （契約プログラミングについて） Effective Java読書会9日目 - 例外 （Javaにおける例外の扱いについて） 契約による設計から見た例外 （この記事の方がより詳しいけど難しいイメージ） チェック例外と非チェック例外の違い チェック例外→「回復
AngularJSで、ブラウザのJavascriptエラーをサーバーに送る - Qiita
クライアントのエラーをキャッチする この記事を読みました。 WEBブラウザで起きた JavaScript のエラーをサーバに送りたい 素晴らしいアイデアですが、AngularJSでは、window.onerrorが発火しないため、通常のやり方が通用しません、とのこと。 そのため、$exceptionHandlerという、例外を集約しているサービスをオーバーライドする必要があります。 以下のように書けば問題ないかと思われます。 angular.module('myApp') .factory('$exceptionHandler', function($injector) { return function errorCatcherHandler(exception) { // オーバーライドしたためブラウザにエラー出力しないので、ここからブラウザにエラー出力する console.error
例外処理の落とし穴 - Qiita
言語側で実装されていれば、なかば強制的に使うことになりますし、そして正常系の処理と異常時の処理をスッキリ分離できるので便利な例外処理ですが、開発の過程では逆に厄介な現象を招くこともあります。 例外処理の基本 C++やJavaScriptなどでは、例外としてどんなものでも投げることができますが、RubyやJavaでは、特定の基底クラスから継承したものしか例外として投げることはできません。 そして、例外クラスはたいていの場合、継承ツリーを通じていくつかに区分されています。Javaであれば「処理系自体の異常（Error）」、「チェック例外（Exception）」、「非チェック例外（RuntimeException）」、Rubyでは「通常実行時に起きる例外（StandardError）」、「それ以外の例外（Exception）」となっています。そして、Javaでは検査例外がありますが、Rubyでは
#error_handling_sushi でPromiseのエラーハンドリングについて発表した
#error_handling_sushi でJavaScriptのエラーハンドリングについて議論した。 自分はPromiseのエラーハンドリングの握りつぶしの問題を見つけやすくするイベントの実装について、Promise Error Handlingという話をした。 ログ: #error_handling_sushi - Togetterまとめ #error_handling_sushi 始まった #寿司とは pic.twitter.com/XZe21QTsDO — Takuto Wada (@t_wada) March 6, 2015 – 基調講演 - teppeis これが #error_handling_sushi pic.twitter.com/vSLDpthYi4 — azu (@azu_re) March 6, 2015 #error_handling_sushi 基調講演 一
例外入門以前 - Qiita
例外 Advent Calendar 2014の継続について 参加者が集まらなかったという経緯から独りAdvent Calendarとして始めた「例外 Advent Calendar 2014」ですが、諸事情により継続が困難となったため私Kokudoriの6日以降の投稿はありません。変に注目だけを集める形になってしまい申し訳ありません。 以下、諸事情というか、言い訳。 『契約による設計から見た例外』という記事にて述べた「契約」に対する私の理解が根本的に間違っていました。 そこから芋づる式に例外に関する私自身の考えが間違っていた、あるいは理解が浅かったことに気づきました。このような理解力では例外について私見を述べることさえ不可能となり、結果頓挫という形になりました。 考えうる限り最低で残念な結果になってしまいました。本当に申し訳ございませんでした。 初めに原則を考え出して、それから例外を見つ
例外処理の書き方について - Qiita
public class hogeAction { public String main() { try { ・・・ ビジネスロジック ・・・ } catch (Throwable e) { return null; } return foo; } } このようになんでもCatchしちゃう包容力の高いコードをたまに見る。 こういうコードを見つけると、「臭うぞ！！」と思うのは自分だけだろうか？ まあ直接的すぎるのもあれなので、 「ちょっと例外処理広すぎやしませんか？ 例外処理は必要最低限の範囲で意図したものだけCatchしましょうよ」 くらいにレビューフィードバックしたりする。 言語やチームに限らず、ここまで激しくなくても、必要以上に大きくTry Catchで囲って必要以上にCatchする書き方をするエンジニアを数多く見てきた。 なぜこういうコードが生まれるのか あまりにも多いので、こういう
サービス終了のお知らせ
平素より「PHPプロ！」をご愛顧いただき、誠にありがとうございます。 2006年より運営してまいりました「PHPプロ！」ですが、サービスの利用状況を鑑みまして、2018年9月25日（火曜日）をもちましてサービスを終了させていただくことになりました。 サービス終了に伴いまして、2018年8月28日（火曜日）を持ちまして、新規会員登録ならびにQ&A掲示板への新たな質問、回答の投稿を停止させていただきます。 なお、ご登録いただいた皆様の個人情報につきましては、サービス終了後、弊社が責任をもって消去いたします。 これまで多くの皆様にご利用をいただきまして、誠にありがとうございました。 サービス終了に伴い、皆様にはご不便をおかけいたしますこと、心よりお詫び申し上げます。 本件に関するお問い合わせはこちらよりお願いいたします。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tracebackをログに残す場合のお約束コード - methaneのブログ
pythonの例外でstack traceを表示する - Qiita