タグ

Haskellとerrorに関するnsyeeのブックマーク (12)

  • 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での例外処理(その2) - あどけない話
  • Haskell での例外処理 - あどけない話

    リツイート数が30を超えたので、Haskell での例外処理について説明します。僕が思うに、Haskell での例外処理が分かりにくいのには、2つ理由があります。 ライブラリの混乱 パラダイムの違い 歴史的経緯により、Prelude にも Control.OldException にも Control.Exception にも catch があります。歴史的経緯を説明するのは面倒なので、これだけ覚えて下さい。「Control.Exception だけを使って、それ以外は忘れる」 そもそも純粋関数型で catch とか言われても分からないかもしれません。Haskell では、純粋な関数と IO とでは、例外処理の方法が異なります。命令的な catch などを使うのは IO です。純粋な関数には Maybe か、Either を使います。 純粋な関数 純粋な関数では、原則として例外を投げてはい

    Haskell での例外処理 - あどけない話
  • 言語女子会: undefとnullは両方必要? - 西尾泰和のはてなダイアリー

    Twitterのタイムラインが面白すぎて、ついうっかり言語を擬人化して脳内で言語女子会なるものを開いてしまいました。なお、登場人物と実在の人物は1対1に対応しません。 undefinedとnullの両方必要なの? とあるプログラミング言語が集う女子会にて: Perl: そういえばさ、なんでJavaScriptちゃんってundefinedとnullの両方もってるの? JavaScript: えっ、未定義の変数にアクセスした時undefined返したいじゃない? Python: 例外投げて死ねばいいじゃん Ruby: 例外投げて死ねばいいよね Python & Ruby: ねー♡ Java: いやそこは参照型ならnull、数値型なら0で初期化すべきでしょ C: これだから最近の若い子は…初期化にだってコストが掛かるんだからね!デフォルトで初期化するなんて無駄遣いよ!必要な人だけが責任をもって初

    言語女子会: undefとnullは両方必要? - 西尾泰和のはてなダイアリー
  • A brief tutorial-introduction to 'fclabels' 1.0 | Brandon Simmons' website

  • http://blog.ezyang.com/2012/01/modelling-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

  • エラー処理を書いてはいけない - Preferred Networks Research & Development

    昨日セミナーとして USTREAM させていただいた資料を公開いたします。 エラー処理を書いてはいけない USTREAMのビデオ タイトルは釣り気味ですが、内容はいたって真面目なのでご安心ください。 概要 やってはいけないシリーズ、の第三弾としての試みです。 リソース管理をしてはいけない ロック処理を書いてはいけない エラー処理を書いてはいけない ← New! タイトルに反して(あるいはタイトル通りに)、正しく長時間動作するプログラムを書くには きちんとエラー処理を行う必要がありますが、 それを何とか抽象化しようという(Haskell界隈での)試みについてのご紹介でございます。 あまり他の人がこういうことを言っているのを聞いたことが無いので、 自分の日々考えていることを世に問うた形になっております。 実際のところ、社内ではC++がメインに使われておりますので、 こういう手法が用いられている

    エラー処理を書いてはいけない - Preferred Networks Research & Development
  • http://blog.ezyang.com/2011/08/8-ways-to-report-errors-in-haskell-revisited/

  • 必ず成功させるという設計選択 - Faith and Brave - C++で遊ぼう

    リストの先頭要素を取得するPreludeのhead関数は、空リストを与えると失敗します。 「1要素以上なら必ず成功する」という大半の状況でうまくいく処理のためにエラーハンドリングをするのはめんどくさいですし、エラーの可能性を残すというのは不安です。現状では必ず1要素以上のリストが渡されるけど、将来もしもここの箇所に0要素で来たら落ちるかもしれないからエラーハンドリングしておこう、という、現状では無駄なコードを書くことになるかもしれません。 この問題へのアプローチとして、「必ず1要素以上が入ることが保証されたリスト」を定義することで、エラーハンドリングすらさせない、というものが考えられます。 以下はHaskellで書いたものです。 type NeverEmptyList a = (a, [a]) front :: NeverEmptyList a -> a front xs = fst xs

    必ず成功させるという設計選択 - Faith and Brave - 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

    エラーハンドリング勉強会で発表してきました - Yet Another Ranha
  • 1