node-gypではまった - WebService::Blog->new( user => ’hide_o_55’ )
node-murmurhash3とかnode-kyteaのGYP対応をしていてはまったのでメモ。 node-gypが生成するMakefile等ではいくつかのオプションがデフォルトで付加される。その中に "-fno-exceptions" が含まれているため、C++ Addon で例外処理をしている場合に例外オブジェクトが未定義となりコンパイル時にエラーとなる。 そこで、以下のようオプション名に'!'を付加してデフォルトのオプションを打ち消す必要がある。 { 'targets': [ { 'target_name': 'kytea', 'sources': ['src/node_kytea.cc'], 'cflags': ['-fexceptions'], 'cflags_cc': ['-fexceptions'], 'cflags!': ['-fno-exceptions'], 'cfla
java-ja の例外とロギング勉強会で発表してきました - 純粋関数空間
例外の勉強会をやるので、是非にというお話を頂いて、 LOG.debug(“nice catch!”) というイベントで発表させていただきました。 当日の資料はこちらでご覧になれます。 エラー処理の抽象化 昨年末頃に社内セミナーで発表した エラー処理を書いてはいけない をもうちょっと抽象的に、あるいは具体的な話を入れて焼き直したような内容です。 今回は java-ja さんの勉強会という事で、 なにやらモヒカンとかマサカリとかが飛んでくるらしい、 とんでもないところに来てしまったとビクビクしていましたが、 この難局も何とか乗り切りました。はい。 皆さんとても真面目にソフトウェアエンジニアリングについて議論していて、楽しかったです。 僕は普段Javaでコードは書かないのですが、 Javaだと普通こうする的なのが垣間見えて、 いろいろJavaのバッドノウハウ（あるいはグッドプラクティス）が学べま
Haskellでの例外処理(その2) - あどけない話
Haskell での例外処理の続き。今日は例外を投げるよ！ throwIO IO の中で、例外を投げるには throwIO を使います。 throwIO :: Exception e => e -> IO a Exception型クラスのインスタンスを渡せばよさそうです。Control.Exceptionのマニュアルを読むと、Exception型クラスのインスタンスとして、IOException や ArithException があるのが分かります。 この中から、データ構成子が公開されているものを探してみましょう。ArithException は、データ構成子を公開していますね。その一つである、Overflow という例外を投げてみましょう。 > :m Control.Exception Control.Exception> throwIO Overflow *** Exception:
Haskell での例外処理 - あどけない話
リツイート数が30を超えたので、Haskell での例外処理について説明します。僕が思うに、Haskell での例外処理が分かりにくいのには、2つ理由があります。 ライブラリの混乱 パラダイムの違い 歴史的経緯により、Prelude にも Control.OldException にも Control.Exception にも catch があります。歴史的経緯を説明するのは面倒なので、これだけ覚えて下さい。「Control.Exception だけを使って、それ以外は忘れる」 そもそも純粋関数型で catch とか言われても分からないかもしれません。Haskell では、純粋な関数と IO とでは、例外処理の方法が異なります。命令的な catch などを使うのは IO です。純粋な関数には Maybe か、Either を使います。 純粋な関数 純粋な関数では、原則として例外を投げてはい
PHPの組み込み関数で例外を発生させる方法
このエントリではPHPの組み込み関数でエラー時に例外を発生させる方法を紹介します。デフォルト状態では、PHPの組み込み関数の大半はエラー時に例外を発生させません。 前のエントリで、PHPのheader関数は戻り値を返さず、エラー時に例外も発生させないことを紹介しました。これは酷い仕様だと思うのですが、どうすればエラーハンドリングできるかを考えてみました。 header関数の場合、エラー（警告）そのものは出ているので、以下の二つの方法が候補として考えられます。 error_get_last関数で直近のエラーを取得してエラー処理する set_error_handlerで定義したエラーハンドラ関数でエラー処理する どちらもモダンな書き方とはほど遠い感じです。 前者は、BASICのon error resume nextを連想させますし、直近のエラーがどの箇所で起こったかは簡単には識別できないので
BDD on Haskell チュートリアル その3-3 : 仕様変更はテストから
前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 Haskell の浮動小数点小数の同値比較について BDD on Haskell チュートリアル その1 : HUnit で TDD を BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト BDD on Haskell チュートリアル その3-1 catch できない哀しみ BDD on Haskell チュートリアル その3-2 throw Exception を使わず基本は Either を使おう 今回のテーマ - 「テスト済みのモジュールの仕様変更」前回書いたように，IO が絡まないはずの関数群に Exception を throw させるよりは Either <Error> <Success>
BDD on Haskell チュートリアル その3-2 : throw Exception を使わず基本は Either を使おう
前回の続き．前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 Haskell の浮動小数点小数の同値比較について BDD on Haskell チュートリアル その1 : HUnit で TDD を BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト BDD on Haskell チュートリアル その3-1 : catch できない哀しみ 「どちらか」を表現する Either 型Control.Exception の try catch finally はそもそも IO モナドで利用される事を想定している．つまり 外部からの入力や Haskell の実行結果を出力する境界で発生する予期しない事態に対応する為のものだ． なので，IO に本当は依存してな
BDD on Haskell チュートリアル その3-1 : catch できない哀しみ
前回までのエントリーはこちら BDD on Haskell の為のディレクトリ構成を考える BDD on Haskell チュートリアル その0 Haskell の浮動小数点小数の同値比較について BDD on Haskell チュートリアル その1 : HUnit で TDD を BDD on Haskell チュートリアル その2 : QuickCheck でランダムテスト 前回までで，ほぼ TDD BDD の基本は書いたのだけど，今回は例外について． Haskell の例外処理Haskell も普通の言語よろしく，例外処理は throw try catch 使える．けれど IO が絡んでくる場合でないとあまり有用ではない印象． throw try catchHaskell の try catch throw finally は Control.Exception モジュールで定義され
Partial Function Considered Harmful - 純粋関数空間
この記事は、Haskell Advent Calendar 2011 25日目の記事として書かれました。 概要 Haskell、あるいはその他のプログラミング言語では 「部分関数(Partial Function)」 と呼ばれるものが標準ライブラリに存在したり、 定義したりすることができます。 今回はそれらが有害であるという考えと、 代替の紹介をしようと思います。 部分関数とは 部分関数(Partial Function)とは、 集合の言葉で言うと、 定義域(domain)の要素に対して、値域(range)の値が高々1つ対応付けられる ような対応付けのことです。 Haskellでは 「結果の値が引数によっては定義されないことがあり得る」 関数だと言えます。 例えば、整数の割り算を行う関数 div :: (Int, Int) -> Int は、 (1, 0) に対しては定義されません。 Ha
モナドトランスフォーマーとmonad-control - maoeのブログ
アドベントカレンダーのいいネタが無いなあと思っていたところ、ちょうど週末にあたらしいmonad-controlがリリースされたので、これを紹介したいなと思いました。 その前に、モナドトランスフォーマーというかっこいい名前の代物の話をちょっとだけしましょう。 モナドトランスフォーマーと例外処理 Haskellerの皆さんはきっと息をするかのように自然にモナドを使っていることと思います。標準で提供されているモナドは単機能なので、組み合わせたくなってきます。必然的に皆モナドトランスフォーマーに手を伸ばすわけです。実際のアプリケーションのコードを書くと、多くのモナドではベースモナドがIOになるでしょうから、今度は自作したカスタムモナドスタックでIOが投げる例外をハンドルしたくなるわけです。 ここでふとControl.Exception.catchの型をみると Prelude> :t Control
エラー処理を書いてはいけない - Preferred Networks Research & Development
昨日セミナーとして USTREAM させていただいた資料を公開いたします。 エラー処理を書いてはいけない USTREAMのビデオ タイトルは釣り気味ですが、内容はいたって真面目なのでご安心ください。 概要 やってはいけないシリーズ、の第三弾としての試みです。 リソース管理をしてはいけない ロック処理を書いてはいけない エラー処理を書いてはいけない ← New！ タイトルに反して（あるいはタイトル通りに）、正しく長時間動作するプログラムを書くには きちんとエラー処理を行う必要がありますが、 それを何とか抽象化しようという（Haskell界隈での）試みについてのご紹介でございます。 あまり他の人がこういうことを言っているのを聞いたことが無いので、 自分の日々考えていることを世に問うた形になっております。 実際のところ、社内ではC++がメインに使われておりますので、 こういう手法が用いられている
エラーハンドリング勉強会で発表してきました - Yet Another Ranha
発表資料はココで : http://ranha.kerox.info/start_exception.pdf 全体構成は3部です。 しかし、そのうち1つは、Exceptional C++とか(何か聞く所に依るともっと適切な本があるらしいですが)読むと例外安全とか例外中立を一々気にする姿勢について分かるし良いのではないでしょうか、ということの紹介みたいなものなので、実質2つです。 Haskellのパートは,StackのPushを何も気にせず代数的データ構造で表現すると data Stack a = Empty | Push a (Stack a) となって、このPushの型が -- Push :: a -> Stack a -> Stack a Stack aというEmptyであるかもしれない型を返すのが良くない。 更に、PopってPushの逆操作だからーということで pop :: Stac
Haskellでのエラーの扱い方。あるいはApplicative, Monad等とliftが多くなることについての考え。
@tanakh 師と @nushio による会話を横からメモしたもの。 - Haskellではエラーは型に追い出すのが正攻法。Pureな計算からErrorが飛び出てくるのは対処しようがないので避けるべき。 - 型に追いだすと最終的にすべての操作が例えばMonadの中で行われることになる。それをどう考えるか。 続きを読む
Haskellのエラー処理とMonadCatchIOの落とし穴 - 純粋関数型雑記帳
（この記事はHaskell Advent Calendar jp 2010のために書かれました） Haskellではエラー処理に例外が用いられます（MaybeモナドやErrorモナドも用いられますが、ここでは例外に焦点をあてます）。 例外インターフェースの話 Haskellにも、例外を扱うためにtry, catch, finallyなどが用意されています。他の多くの言語ではこれらは構文として用意されますが、HaskellではIOモナドを引数にとる関数になっています。 try :: Exception e => IO a -> IO (Either e a) catch :: Exception e => IO a -> (e -> IO a) -> IO a finally :: IO a -> IO b -> IO a tryはIOアクションを引数にとり、それを実行した結果が正常に値を返
Node.js + Websocket Canvas共有システムが時折ダウンする問題について
2010/10/27にCanvas共有Websocketサーバーを作動させて以来、サーバーがのべ三度にわたりダウンするという問題が発生していました。原因の究明を進めていたところ、一部ダウンする状況の再現及び対処法を突き止めましたのでご報告申し上げます。なお、ダウン中にアクセスされ、Canvas共有を体験なさることが出来なかった読者の方々には深くお詫び申し上げます。これからもダウンの折には早急な原因の解明と対処に努めますので、どうか今後ともよろしくお願いいたします。 サーバーダウン時のエラー出力の内容 node.js:63 throw e; ^ Error: ECONNRESET, Connection reset by peer at Stream._readImpl (net:304:14) at IOWatcher.callback (net:454:24) at node.js:76
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.ezyang.com/2012/01/modelling-io/
http://blog.ezyang.com/2011/08/8-ways-to-report-errors-in-haskell-revisited/
mjijackson/error - GitHub
GitHub - CrabDude/trycatch: An asynchronous domain-based exception handler with long stack traces for node.js
GitHub - 3rd-Eden/cluster.exception: Exception handler for cluster