または私は如何にして例外するのを止めて golang を愛するようになったか — KaoriYa
Java の finally よりも golang の defer のほうが筋が良さそうだ、 ということから考え始めた結果、 どうして私が golang を気に入ったのかがわかった気がしたので書いておきます。 ファイルをオープンし読み込みな処理で何かして終わったら閉じる、という関数を Java と golang で書き比べてみましょう。 Java で書くとこんな感じですね。 public static void readFile(String fname) throws IOException { InputStream s = null; try { s = FileInputStream(fname); // // Do something with "s". // } finally { if (s != null) { s.close(); } } }
Big Sky :: golang で複数のエラーをハンドリングする方法
golangいまどき例外ないの頭おかしいって思ってたけどようするにgoroutineと例外がうまくいかないからgoroutineのほう取って例外捨てたってことかねえ。 — Urabe, Shyouhei (@shyouhei) April 15, 2014 FAQ に書いてあります。 Why does Go not have exceptions? - Frequently Asked Questions (FAQ) - The Go Programming Language We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programme
scala.util.Tryが使いづらい？
Kenji Yoshida @xuwei_k 「scala.util.Tryが嫌いな理由」という感じでブログ書こうとして、そういえばtwitterから来たわけだし「改めてTryが使われてるコードを見なおしてから記事書こう！」と、(おそらく一番多く使われているであろう)finagleのコード見たら、複雑で理解できなくて死・・・ Kenji Yoshida @xuwei_k scala.util.Tryについて言えるのは「失敗をThrowable型でしか持てない」のが大きな特徴で、Throwable以外のもっと扱いやすいオブジェクトにその場で変換できるならTryいらない(?)とか、じゃあThrowableってそもそも何？とか考える必要がある気がして
例外処理 - Wikipedia
例外処理（れいがいしょり、英語: exception handling）とは、IT業界で用いられる専門用語で、ある抽象レベルにおけるシステムの設計で想定されておらず、ユーザー操作によって解決できない問題に対処するための処理である。例外処理の結果として問題が解決されないとシステム障害になる。システム停止やデータ破損の原因になり、ユーザーに損害を与える可能性があるため、システム開発で例外処理は重要視されている[1][2][3]。 システムの設計で想定されておらず、継続不能や継続すると問題になる様な状態としては、次のようなものが挙げられる。 ハードウェアの故障 オペレーティングシステム等、システムの設定ミス ライブラリの欠損 ユーザーの入力間違い 数値入力を要求している場合での、英単語の入力 存在しないデータベースのテーブル／カラムやファイルの指定 必要な他システムとの疎通が取れない 許されない
Scala Tips / Scala 2.10味見(10) - Try(2)
TryとEitherは2つの状態による計算文脈を表現するという意味ではよく似たオブジェクトですが、Tryはファンクタ(Functor)かつモナド(Monad)であるのに対してEitherはそうではないという点が異なります。 Eitherは直和の性質を表現するために2つの状態を同じ比重で扱いますが、この点を徹底するためにファンクタやモナドにはしていないと思われます。EitherではLeftProjectionやRightProjectionと組み合わせることによって、ファンクタ的、モナド的な使い方も可能ですが使い勝手がよいとはいえません。 正常状態と異常状態の2つの状態を扱う場合、(1)出現頻度は正常状態の方が多い、(2)正常状態に対するロジックは複雑/異常状態に対するロジックは単純、(3)一度異常状態になると以降は異常状態を保持、となるケースが多いと思います。このようなケースでは、正常状態
Scala 2.10.0 Try ＆ NonFatal - CLOVER🍀
なんか、情報だけチラチラ見かけていて気になっていたので。まあ、半分くらいFutureの時に使っているのですが。 Try Futureの結果として使っていた、SuccessとFailureの親クラスです。Successが成功、Failureが失敗を表すわけですが、Failureは例外を情報として持ちます。それ以外はSuccessですと。 Futureの時は、計算結果がSuccessまたはFailureとして得られましたが、これを単独で使う場合にはTryコンパニオンオブジェクトのapplyメソッドを使用します。 println(Try { 10 }) // => Success(10) println(Try { throw new Exception("Oops!") }) // => Failure(java.lang.Exception: Oops!) Try.applyのシグネチャは
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-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++がメインに使われておりますので、 こういう手法が用いられている
エラーハンドリング勉強会で発表してきました - 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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - yuskesh/jsdojo: This repo includes additional material on JSDojo#1
http://blog.ezyang.com/2012/01/modelling-io/
http://blog.ezyang.com/2011/08/8-ways-to-report-errors-in-haskell-revisited/