[Python] 例外処理のやり方と、スタックトレース取得の実装方法 - YoheiM .NET
こんにちは、@yoheiMuneです。 久しぶりのブログ、書きたいことがいっぱいです。プログラムでエラーが発生した時に重宝されるスタックトレース。Python言語におけるエラーハンドリングの方法と、そこでのスタックトレースの取得方法を、今日はブログに書きたいと思います。 目次 スタックトレースとは スタックトレースは、プログラムで例外が発生した際に、どのように関数が呼び出されたのか、どこでエラーが発生したのか、を特定できる情報です。不具合発生時の原因究明に、重宝されます。例えば以下のプログラムがあるとします。 def a(): """b関数を呼び出す""" b() def b(): """c関数を呼び出す""" c() def c(): """例外が発生する""" char = None char.format('hello') # ここで例外発生 # a関数から呼び出してみる a() こ
![[Python] 例外処理のやり方と、スタックトレース取得の実装方法 - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/cad8bf80dce70a2c781213002e058c5d127026e2/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2F622.jpg)
JavaScriptエンジニアなら知ってるよね？ エラー処理のいい書き方、悪い書き方
JavaScriptのエラー処理、ちゃんと書いていますか？ エラーを無視せず、どこに問題があるのか、きちんと確認できるコードの書き方をデモで紹介。 この記事はTim SeverienとMoritz Krögerが査読を担当しています。最良の記事を提供することができ、SitePointの査読担当者の皆さんに感謝します。 JavaScriptのエラー処理には危険が潜んでことを知っていますか？ もしマーフィーの法則を信頼しているとしたら、不具合が生じる可能性が本当に高いです！ この記事では、JavaScriptのエラー処理について考え、その落とし穴から便利な実践例までを説明します。さらに最後には、非同期コードとAjaxにも触れます。 JavaScriptはイベント駆動型プログラムで、プログラミングをより豊かなものにしてくれます。ブラウザーをイベント駆動型プログラムと考えると、発生するエラーは同一
Node.js における Promise を使った例外処理 - from scratch
さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基本的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(
Java/Androidにおける例外設計、あるいは「契約による設計」によるシンプルさの追求 - Qiita
なぜ今Javaの例外処理か Javaにおける「チェック例外」はSwift、Objective-C、Ruby、JavaScriptといったネイティブ・ウェブアプリ開発でよく用いられる他の言語には現れないものです。 SwiftにはOptionalやErrorTypeがありますが、Javaにおいてもnullやエラーのハンドリングの実装方法をうまくやる必要があります。 なぜ例外を握りつぶしたらいけないのか、なぜアサーションが望ましいのか、なぜチェック例外と非チェックを分けたのか、という点を考えてみたいと思います。 参考資料 例外設計における大罪 （契約プログラミングについて） Effective Java読書会9日目 - 例外 （Javaにおける例外の扱いについて） 契約による設計から見た例外 （この記事の方がより詳しいけど難しいイメージ） チェック例外と非チェック例外の違い チェック例外→「回復
Javaの例外処理について - 水まんじゅう2
これはJavaアドベントカレンダーの5日目です。 最近例外処理について考えなければいけないことがあったので、こうしたほうが良いよというのをまとめます。 他の言語からJavaに移ってきた場合に微妙なところで変な感じになることがあるので。 ここで扱うJavaの例外というのはThrowableとそのサブクラスのことです。 Javaにはtry〜catch〜finallyという例外を扱うための構文があります。 try { } catch(Throwable t) { } finally { } Java7からはtry-with-resourcesや例外のマルチキャッチという新しい構文も増えました。 そちらについて詳しく知りたい人は[twitter:@skrb]さんの現場で使える[最新]Java SE 7/8 速攻入門をご参照お願いします。 現場で使える［最新］Java SE 7/8 速攻入門 作者:
Javaの検査例外は、呼び出し側で「どんなに注意しても防げない」異常系 - Qiita
注：本記事の内容はJavaで公式にドキュメントされているものではなく筆者の見解です。とはいえクラスを設計する上で有用な指針たり得ると思われるので公開したものです。 おさらい - 検査例外と非検査例外 Javaの例外クラスには「catchしないとコンパイルエラーになる」検査例外（チェック例外、checked exception）とそうでない非検査例外（非チェック例外、unchecked exception）があります。 検査例外は最近は嫌われる傾向がありC#では採用されていませんしAltJava言語も軒並み不採用、さらにはJavaの新しめのライブラリにも非検査例外しか投げないものが出てきていますが、適切に使えば安全なプログラミングのための強力な武器であり、検査例外の有意義さについては @irxground さんの Javaの検査例外の存在意義 をご覧ください。 例外クラスを自作する場合、検査
例外入門以前 - Qiita
例外 Advent Calendar 2014の継続について 参加者が集まらなかったという経緯から独りAdvent Calendarとして始めた「例外 Advent Calendar 2014」ですが、諸事情により継続が困難となったため私Kokudoriの6日以降の投稿はありません。変に注目だけを集める形になってしまい申し訳ありません。 以下、諸事情というか、言い訳。 『契約による設計から見た例外』という記事にて述べた「契約」に対する私の理解が根本的に間違っていました。 そこから芋づる式に例外に関する私自身の考えが間違っていた、あるいは理解が浅かったことに気づきました。このような理解力では例外について私見を述べることさえ不可能となり、結果頓挫という形になりました。 考えうる限り最低で残念な結果になってしまいました。本当に申し訳ございませんでした。 初めに原則を考え出して、それから例外を見つ
Java で UnsupportedEncodingException を発生させなくする - Qiita
こんにちは、最近は Go か Java しか書いていない米林です。 UnsupportedEncodingException 嫌い Java開発において String.getBytes("UTF-8") や new String(byte[], "UTF-8) する際に、毎回 UnsupportedEncofingException を try-catch したり throws に追加して「"UTF-8"はサポートしてるだろう」と思いながら仕方なく書いてた人は日本 には多数いるはずです。 コードとしてはこんな感じ、Java 開発者なら「あー、これね」と頷くレベルですね。 private void getBytes() { final String msg = "ABC"; try { final byte[] bytes = msg.getBytes("UTF-8"); } catch (
例外設計の話
例外設計の話。 こんな指針がいいのかなー 2013 夏 ver. 例外の目的とは？ 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」 via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html .NET の「例外のデザインのガイドライン」にもこう書いてある。 特定の例外が特定のコンテキストでスローされる理由を把握できている場合は、その例外をキャッチするようにしてください。 回復可能な例外だけをキャッチする必要があります。たとえば、存在しないファイルを開こうとした場合に発生する FileNotFoundException は、アプリケーションで処理できる例外です。それは、アプリケーションがユーザーに問題を知らせ、ユーザーが別のファイル名を指定したり、ファイルを作成したりできるようにすることが可能だからで
Androidアプリ開発で例外の発生した場所を特定する | DevelopersIO
以前、「iOSアプリ開発で例外の発生した場所を特定する」というブログを書きましたが、 Androidでも同じような機能があるようです。(むしろ、Javaですが。。。) Thread クラスの setDefaultUncaughtExceptionHandler メソッドというものを使いますが、 ここでオリジナルのクラスをセットすることにより、キャッチしてない例外発生によってアプリが強制終了したときの 「問題が発生したため、xxx(アプリ名)を終了します。」という、みなさんおなじみ？ のダイアログが表示される前に、任意の処理を差し込むことができます。 今回はそれを利用して、例外発生時のスタックトレースを SharedPreferences に保存して、メール送信するサンプルを作ってみます。 開発時などは、アプリをデバッグ起動していればEclipseのLogCatで例外発生時のスタックトレース
Node.jsのコードのエラー処理の書き方: 初歩からより堅牢な書き方まで - memo.yomukaku.net
ファイルの内容のJSONを読んでパースして返す、という単純な処理を行う関数を例にもちい、node.jsのエラー処理の書き方、よくやってしまう間違い、より堅牢なエラー処理の書き方について書きます。test.jsonというファイル名で以下の内容が書かれたファイルを準備しておきます。 { "1": "a", "2": "b", "3": "c" } このtest.jsonというファイルを読み、JSON.parse()して返すreadJSON()という関数を作り、この関数のエラー処理の書き方についてみていきます。 まずは全くエラー処理を行っていない書き方からみます。 例外処理を行っていない書き方 さっそくコードをみます。 // code1.js // 例外処理を行っていない書き方 var fs = require('fs'); function readJSON (path, callback)
非同期APIと例外処理（node.js の domain について）
node.js のような非同期APIを使ったプログラミングに拒絶反応を示すエンジニアが多い理由の一つが、非同期APIと例外処理の相性の悪さだ。 Javascript の場合、例外処理はこんな感じに記述する。 function f(i) { try { throw new Error('an error #'+ i); } catch(e) { console.log('Error caught:', e.message); } } ところが、これに非同期APIが絡むと、とたんに分かりにくくなる。例えば下の例。 function f(i) { try { setTimeout(function() { throw new Error('an error #'+ i); }, 1000); } catch(e) { console.log('Error caught:', e.message)
Rubyで自前の例外クラスを作るときExceptionではなくStandardErrorを継承する理由 - yarbの日記
Rubyの例外について少し調べたので、まとめてみる。 多くのモダンな言語同様にRubyでは例外処理機構が組み込まれている。 ファイルを開こうと思ったらファイルが存在しなかった ネットワーク先のサーバが反応しなくてタイムアウトした 定義されていない（存在しない）メソッドを呼んだ 0で割り算をしてしまった など想定外の問題に遭遇したときに、その問題を無視せずプログラマが何らかの対応処理をするための枠組みを提供する。 C言語など古い言語では、関数からの戻り値でエラーコードを返し、それによって呼び出し側がエラー処理をその場で記述する。例えば、fopen(3)が失敗すると戻り値としてNULLが戻ってきてグローバル変数のerrnoに失敗の理由を示すエラーコードが設定される。 #include <stdio.h> #include <string.h> #include <errno.h> int ma
Beautiful Error Handling
Beautiful Error Handling 田中英行 <tanakh@preferred.jp> 2012年夏のプログラミング・シンポジウム 自己紹介 田中英行 (@tanakh , http://tanakh.jp ) (株)Preferred Infrastructure勤務のプログラマ Haskell 愛好家 BASIC(20年), C++(15年), Haskell(10年) 「すごいHaskellたのしく学ぼう！」 (Learn You a Haskell for Great Good! の和訳) 好評発売中！！ 概要 エラー処理に美しさを！ エラー処理の抽象化 Haskellでのアプローチ エラー処理に美しさを！ 背景 エラー処理は醜くなりがち なんで汚くなるのか？ これまで適切な抽象化が行われて来なかったから なぜそういう状況になっているのか？ 大きな原因の一つはプログ
Javaの例外処理で知らないと損する7つのテクニック
Javaの例外処理で知らないと損する7つのテクニック：【改訂版】Eclipseではじめるプログラミング（24）（1/3 ページ） これからプログラミングを学習したい方、Javaは難しそうでとっつきづらいという方のためのJavaプログラミング超入門連載です。最新のEclipseとJava 6を使い大幅に情報量を増やした、連載「Eclipseではじめるプログラミング」の改訂版となります（この回と前回のみ、別連載「EclipseでJavaに強くなる」の改訂版です。今回は第4回Javaの例外のテクニックを知る」の改訂版です） 前回の「プログラマの宿命！ 例外とエラー処理を理解する」では、Javaにおける例外の用途と基本的なコードの書き方、例外が発生するさまざまなケースについて理解しました。 今回は、独自に例外を定義する方法や、ちょっとした例外のテクニックを紹介します。 【1】Eclipseで独自の
システム系の例外は実行時例外＋AOPでハンドリングするのがベスト - 達人プログラマーを目指して
インフラ層のチェック例外はやはりJavaのBad Partだと思う 先日のJava言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してで、 インフラ層のフレームワークなどでは実行時例外が適切 ということを書いたのですが、この点についてもう少し詳しく考えてみたいと思います。 Java: The Good Partsの本ではRMIの章があるのですが、RMIではRemoteというマーカーインターフェースを継承しつつ、すべてのメソッドがRemoteExceptionというチェック例外を送出する規則となっています。 Java Good Parts（9.1節より引用） pubic interface StatRecorder extends Remote { void recordGame(BoxScore stats) throws RemoteException;
Scalaでの例外処理 - Either,Option,util.control.Exception - ( ꒪⌓꒪) ゆるよろ日記
今日はScalaの例外処理について解説しますよ。 基本 - try,catch,finally 例外処理の基本は、try,catch,finallyです。これはJavaと同じですね。 ただし、Scalaでのtry,catch,finallyは値を生成します。つまり、実行されたブロックの値が評価されます。 scala> val n = try{ "99".toInt } catch { case e:Exception => -99 } n: Int = 99 scala> val n = try{ "foo".toInt } catch { case e:Exception => -99 } n: Int = -99 上記のように、catch節には "case e:Exception => ..."のようなパターンマッチを書くことで、対応する例外の型に応じて補足することができます。try,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP ここで差がつくエラー処理 完全版 #phpcon2017 by 黒點 さん - niconare
Ruby の invalid byte sequence in UTF-8 例外を encode("UTF-8", "UTF-8") で回避するのはおかしいよ、という話 : sonots:blog
http://www.memetodo.co.cc/2011/06/trycatcherror.html