ググるよりもまずはpry - Qiita
Rubyといえば動的型付け言語なので、IDEサポートがほとんど皆無です。 それはしょうがないんですが、やはりIDEサポートはけっこうなアドバンテージに思うわけで。 例えばC#+Visual Studioは素晴らしいです。膨大なBCLも、IntelliSenseがあると結構なんとかなったりします。 もちろんruby環境にも補完機能がないわけではないですが、やはり弱いです。 なのでどうしてもtypo→エラー→ググるというプロセスをよく歩んでしまいます。 そこでpryですよ pryはirb（rubyの標準インタプリタ）の上位版です。 irbで出来ることはpryでも大抵は可能です。 pryにはシンタックスハイライト機能とかもありますが、一番はlsコマンドとcdコマンドです。 例えば適当なstringオブジェクトをlsしてみると "hello pry!"オブジェクトのメソッドが一覧されます。 また、
例外安全と例外中立 - Qiita
現代のC++で例外安全問題を抜きにして、障害に強い強固なコードを書くことはほとんど不可能に近い。以上。 Hurb Sutter [1] 例外処理における目的は、例外の回復と例外の通知の大きく2つあります。残念ながら例外の回復はとても難しく、場合によってはそもそも不可能だったりします。その場合、例外が発生したことをより上位のレイヤーに通知する事で例外処理を託します。この時、例外の通知を受け取った側は何を前提に例外の回復を行えばよいでしょうか。例外の発生によってデータ整合性は崩れてしまっているかもしれません。通知を受け取った上位レイヤーはあらゆる状態を想定して例外の回復を試みなければならないのでしょうか。もしそうだとすれば、ただでさえ難しい例外の回復がいよいよもって現実的ではなくなってしまいます。 明らかに上位レイヤーが持つべき前提条件が存在します。これは例外を通知する側が満たすべき保証と言い
例外入門以前 - Qiita
例外 Advent Calendar 2014の継続について 参加者が集まらなかったという経緯から独りAdvent Calendarとして始めた「例外 Advent Calendar 2014」ですが、諸事情により継続が困難となったため私Kokudoriの6日以降の投稿はありません。変に注目だけを集める形になってしまい申し訳ありません。 以下、諸事情というか、言い訳。 『契約による設計から見た例外』という記事にて述べた「契約」に対する私の理解が根本的に間違っていました。 そこから芋づる式に例外に関する私自身の考えが間違っていた、あるいは理解が浅かったことに気づきました。このような理解力では例外について私見を述べることさえ不可能となり、結果頓挫という形になりました。 考えうる限り最低で残念な結果になってしまいました。本当に申し訳ございませんでした。 初めに原則を考え出して、それから例外を見つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
