タグ

exceptionに関するsbg3のブックマーク (6)

  • リトライ処理を疎結合にできる retriable gem の使用例 - Qiita

    retries = 0 begin 1 / 0 if retries < 2 puts "ok" rescue => exception raise if retries >= 2 sleep(0.5 * 1.5**retries) retries += 1 puts "#{retries}回目のリトライ" retry end # >> 1回目のリトライ # >> 2回目のリトライ # >> ok require "retriable" Retriable.configure do |c| c.base_interval = 0.5 c.multiplier = 1.5 c.on_retry = -> exception, try, elapsed_time, interval { puts "#{try}回目のリトライ" } end Retriable.retriable do |i|

    リトライ処理を疎結合にできる retriable gem の使用例 - Qiita
  • Go ではエラーを文字列比較する?という話について : DSAS開発者の部屋

    Go で関数の戻り値のエラーを判別するときに、エラーメッセージの文字列をチェックするコードが存在します。 (例) これは、 Go が言語設計としてエラー処理が貧弱だったり、標準ライブラリがエラー処理を軽視しているからでしょうか? 言語設計や標準ライブラリのAPIの設計をみて行きましょう。 TL;DR 言語設計としては、Java的例外機構と同等以上の(文字列比較によらない)エラー検査が可能 ただし Go のエラーに関する哲学により、公開されていないエラーが多い 実際にエラーを文字列比較されている実例についての解説 Go のエラー検査方法 Java の例外機構では、例外をキャッチするために専用の構文が用意されており、型によりマッチングすることができます。 これはクラスのツリー構造を利用してサブクラスをまとめて分岐することもできます。 一方で、同じクラスでも値によりエラー処理が異なる場合には、

    Go ではエラーを文字列比較する?という話について : DSAS開発者の部屋
  • 例外設計における大罪 - 契約

    1. 例外設計 における大罪 和田 卓人 (a.k.a id:t-wada or @t_wada) Jun 27, 2012 @ java-ja 12年6月28日木曜日 2. 自己紹介 名前: 和田 卓人 (わだ たくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ・クエスト株式会社 取締役社長 12年6月28日木曜日

    例外設計における大罪 - 契約
  • Failure and Exceptions (James Gosling氏へのインタビューより) - K.Maebashi's はてなブログ

    前回、続きを「数日中に書きます。」と言ったくせにその後いろいろ忙しかったり酒飲んだりしていて書いている余裕がなくて、そうこうしている間に、以前のC#作者Anders Hejlsbergのインタビュー記事へのJames Goslingからの反論を見つけてしまいましたので(こちら経由)また訳してみました。「The trouble with Checked Exceptions」は有名ですし以前から知っていましたが、これの存在は今回はじめて知りました。 例によって私の英語力はアレなので、間違いや訳し切れなかったところについてはご指摘をよろしくお願いいたします。 原文はこちら。 http://www.artima.com/intv/solid.html Summary James Gosling talks with Bill Venners about how to build solid ap

    Failure and Exceptions (James Gosling氏へのインタビューより) - K.Maebashi's はてなブログ
  • 例外処理について、私はこう思う - K.Maebashi's はてなブログ

    他人の意見の翻訳ばかりでもアレなので。 例外処理機構についての私の考え方は、Diksamがそうなっているように、 例外処理機構自体は必要 検査例外も必要 というものです。 例外処理自体の有用性について Joel Spolsky氏の記事の翻訳の感想でも書いたのですが、例外処理機構は必要だと思います。「戻り値でちまちまエラーケースを上位に戻していってうまくいくと思えるほど、私は(自分を含む)プログラマを信用していない」ためです。 Joel氏は 例外を上げるかもしれない関数を呼び、それをその場でcatchしないときはいつも、あなたは、データを整合性のない状態にしたまま突然中断された関数や、あなたが考慮しなかった別のコードの実行経路による驚くようなバグが発生する機会を作り出しているのだ。 と書いていますが、こういうケースは実際に存在します。たとえば(これは「プログラミング言語を作る」に書いた例です

    例外処理について、私はこう思う - K.Maebashi's はてなブログ
  • The Trouble with Checked Exceptions - K.Maebashi's はてなブログ

    JavaからC#に移った人は、C#にはなぜ検査例外がないのか? と疑問に思うと思います。それに対するC#作者Anders Hejlsbergのインタビュー記事を訳してみました(いままでにもまして訳に自信がないところが多いんですが)。 原文はこちら。 http://www.artima.com/intv/handcuffs.html 拙著「プログラミング言語を作る」内でも少し言及しています(p.340)。 ところで、JavaとC#の例外処理の違いというと「検査例外の有無」が取り上げられることが多いのですが、「スタックトレースが生成されるタイミング」も異なっており、Javaプログラマはたまにはまることがあります。その点も「プログラミング言語を作る」では言及しておりますのでぜひどうぞ(宣伝)。 関連記事: MSDN内の記事 http://msdn.microsoft.com/en-us/vcsh

    The Trouble with Checked Exceptions - K.Maebashi's はてなブログ
  • 1