JavaとRubyの例外処理(その2)~メギドの丘~

※この記事は読者によって投稿されたユーザー投稿です:
  • 編集部の見解や意向と異なる内容の場合があります
  • 編集部は内容について正確性を保証できません
  • 画像が表示されない場合、編集部では対応できません
  • 内容の追加・修正も編集部では対応できません

ヒューマンリソシア株式会社はコラム「 JavaとRubyの例外処理(その2)~メギドの丘~ 」を公開しました。

JavaとRubyの例外処理の続きです、前回と併せてお読みくださいませ。

前編は基本構文を比較してみましたが、後編はfinally(ensure)節での挙動について言及を試みます。
JavaとRubyを例外処理にて比較した場合にも、やはり実行形態(処理系)が異なる点が
コーディングにおいても相違点の一因になると考えられます。

Javaではソースコード中にライブラリのメソッドが例外をスロー(送出)し例外チェックが必要な場合に、
コード内に例外処理を記述しないとコンパイルエ ラーになります。
例外発生が予期される箇所を事前に教えてくれると理解出来ます。
適切な例外ハンドラを用意しなさいという教えを請うのです。
(但し、RuntimeExceptionサブクラス等は例外チェックがありません。)

その反面、Rubyの場合には処理系がインタプリタのためにコンパイル手順そのものがありません。
Rubyがスクリプト用途としての簡易実行が可能であり、つまり自由度が大きい分、
プログラマにその責務を委ねているとも思えます。(RubyMotionというRubyコンパイラも最近登場です。)
例外発生時には、catch(rescue)節で指定した例外を捕捉して適切な処理を実施すべきですが、
catch(rescue)節を省略した場合にはデフォルトのエラー処理がなされます。
(よく画面で見かけるあのメッセージです。)

この続きは以下をご覧ください
http://resocia.jp/column/674/

この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

アーンドメディア
「トリプルメディア」の 1 つ。ユーザーの「信用・評判・共感」を得るためのメディ ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]