Rustのパニック機構 - 簡潔なQ
概要: Rustのパニック機構は異常終了の処理を安全に行うためにある。この動作を詳しくみていく。 パニックとは何か Rustには2つの異なる例外処理機構があります。 発生源 対処方法 例 パニック プログラミングエラー 原則として捕捉しない assert!() 境界外参照 Result 例外的な入力 必要に応じて捕捉 I/Oエラー (File::read) パースエラー (str::parse) パニックとResultの関係についてはTRPL第2版第9章、未定義動作とパニックの関係についてはRustonomiconのUnwindingの章などが参考になります。 パニックを想定した安全性 Rustではたとえパニック状態でも未定義動作だけは絶対に避ける必要があります。そのため以下の関数は不健全 (unsound)です。 use std::ptr; // この関数はRustではunsound (
Golang の defer 文と panic/recover 機構について - CUBE SUGAR CONTAINER
Golang の defer 文と、それにまつわる panic/recover 機構について調べたので、その内容を書き残しておくことにする。 Golang では defer 文を使うことで、それを呼び出した関数が終了する際に実行すべき処理を記述することができる。 例えば関数の中でオープンしたリソースを確実にクローズするために使われたりする。 試してみよう まずは、シンプルなサンプルコードを使って defer 文の動作を確認してみることにする。 内容的にはメッセージを標準出力に出すということしかやっていない。 ただし、片方には defer が付いていて、もう片方には何もついていない。 コードの記述順序的には "End" のメッセージが先に来ているが、実行するとどうなるだろうか。 package main import ( "fmt" ) func helloworld() { defer f
C++に提案されている静的例外
C++に静的例外が提案されている。 [PDF] P0709R1: Zero-overhead deterministic exceptions: Throwing values 例外はそのパフォーマンスへの影響が懸念され、一部のC++プロジェクトではコンパイラーオプションによって例外自体が無効化されていた。 これは由々しき事態だ。というのも、例外は標準C++の機能の一部であり、標準ライブラリは例外の存在を前提にして設計されている。例外が無効化されているということは、それはもはやC++ではない。C++風の別言語を使っていることになる。 なぜ例外は忌避されるのか。例外のパフォーマンスが非決定的だからだ。例外の実装はスタックからの確保ではなくヒープからの動的なメモリ確保が必要で、例外のキャッチにはRTTIによる型情報の比較が必要だ。 ifとgotoによるエラー処理のパフォーマンス特性は決定的に見
NaN === NaN が false な理由とutil.isDeepStrictEqual - from scratch
NaN === NaN は false NaN、つまりは Not a Number 同士の同値比較が false になるのは、よく JavaScript とかで罠だと言われていますが、罠でもなんでもないです。 false が返るという仕様です。仕様の経緯を追うとすぐに『 IEEE754 という浮動小数点の標準規格で決められているから』、という理由がヒットします。 では IEEE754 ではなんで NaN == NaN を false にしようという話になったのか、というのを調べてみました。 今回はそういう歴史の話です。 IEEE754 現在のプログラミング言語の処理系の多くが採用している浮動小数点の標準規格です。 この標準規格は以下のことを定義している。 - 基本形式: 二進および十進の浮動小数点数データの集合。有限な数（符号付ゼロと非正規化数を含む）、無限、特殊な「数ではない」値（NaN
ScalaでWebアプリケーションのエラー処理を綺麗に書く - はこべにっき ♨
Play Frameworkにおいて、POSTリクエストから得られたbody中のパラメータをもとに何か処理をするというよくあるコードを、ちょっと整理して見やすくする方法を学んだのでメモがてら御シェアさせていただきます。Playのリクエストハンドラを書くときに頻繁に現れたので、例がPlayのコードになっているけど、内容的にはScala全般的な話だと思う。Scalaプロみたいな人にはまったく新しいことはないと思う。 本題と関係ないけど、YAPCでScalaの話をするかもしれません。言語自体の話よりかは採用理由とか開発フローの話を、これまでのPerlでのWeb開発を踏まえて話す感じになりそう。Scala In Perl Company : Hatena - YAPC::Asia Tokyo 2014 さて、本題ですが、話題の対象になるのは以下の様なPlayFrameworkのコードです。 def
ScalaのOptionステキさについてアツく語ってみる - ( ꒪⌓꒪) ゆるよろ日記
今日は、ScalaのOptionの使い方について解説しますよ。OptionはScala使いにとってはなくてはならないものです。これを覚えてしまうと他の言語でもOptionを作りたくなる、かもしれない? Optionってなに? Option型は、値があるかないか分からない状態を表すものです。「Maybeモナド」とか言ってしまうとアレですがまぁそんなようなものらしいです。 Optionの定義 まずは、Optionの定義から見てみましょう。Option型は、抽象クラスOption[+A]と、Option[A]を継承して値がある場合のSome[+A]型とNoneオブジェクトがあります。 Option - Scala Standard Library API (Scaladoc) 2.10.0-20120530-022829-8d38079ab4 - scala.Option // Optionの抽
ScalaのOptionとEitherで例外処理を行う方法 - $shibayu36->blog;
Scalaの例外処理はOptionとかEitherを利用するっぽいんだけど、調べてもいまいちその使い方が分からなかった。いろいろやってみたところ、だいぶ分かってきたので、後から自分で読み返せるようにメモ。 Optionを利用する Optionは値があるかないかわからない場合に、ラップして返してくれるもの。値がある場合はSome()に値が包まれて返ってきて、ない場合はNoneが返ってくる。エラーの内容が特に必要がない場合の例外処理に便利。 パターンマッチで例外処理をする SomeとNoneでパターンマッチすれば例外処理できる。こんな感じ。 val map = Map("a" -> 1, "b" -> 2) map.get("a") match { case Some(n) => println(n) case None => println("Nothing") } map.get("c")
例外入門以前 - Qiita
例外 Advent Calendar 2014の継続について 参加者が集まらなかったという経緯から独りAdvent Calendarとして始めた「例外 Advent Calendar 2014」ですが、諸事情により継続が困難となったため私Kokudoriの6日以降の投稿はありません。変に注目だけを集める形になってしまい申し訳ありません。 以下、諸事情というか、言い訳。 『契約による設計から見た例外』という記事にて述べた「契約」に対する私の理解が根本的に間違っていました。 そこから芋づる式に例外に関する私自身の考えが間違っていた、あるいは理解が浅かったことに気づきました。このような理解力では例外について私見を述べることさえ不可能となり、結果頓挫という形になりました。 考えうる限り最低で残念な結果になってしまいました。本当に申し訳ございませんでした。 初めに原則を考え出して、それから例外を見つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外設計における大罪 - 契約