Checked Exceptions（チェック例外） - Strategic Choice
師曰く明示的に宣言することによって、その例外が必ずキャッチされるようにしなさい。どういうこと？Javaにはチェック例外が存在します。プログラマが明示的に宣言し、コンパイラによるチェックが行われる例外です。コード内でチェック例外がスローされる場合は、その例外をキャッチするか、転送するかのいずれかを必ず行うことになります。どうして？スローされてもキャッチされない例外がさらに大きなリスクとなるのは、例外をスローするコードと、キャッチするコードをそれぞれ別の人が書いている場合です。コミュニケーションの行き違いが、例外のキャッチし忘れによる、突然のプログラム終了を招くことになります。しかし、プログラムが異常終了するときには、せめて状況を診断するための情報を出力したり、ユーザーに何が起きたかを伝えたりするなどの制御が必要です。このような「突然死」を避けるために、チェック例外を使用します。どうすれば？と
Exception Propagation（例外の伝播） - Strategic Choice
師曰く受け取る側にとって適切な情報が含まれるように、必要に応じて変換しながら、例外を伝播させなさい。どういうこと？下位レベルの例外をキャッチしてそのまま報告するのではなく、上位レベルに変換してから、例外を伝搬します。 どうして？例外はさまざまな抽象レベルで発生します。下位レベルの例外をキャッチしてそのまま報告するのは、とくにエンドユーザが見る所まで行ってしまうと、混乱を生じさせるだけです。よって、上位レベルの抽象概念の観点から説明可能な例外に変換して再スローすべきです。どうすれば？「例外翻訳」「例外連鎖」を行います。 下位レベルの例外には、不具合の解析を行う上で重要な情報が含まれていることが多いです。下位レベルの例外は、上位レベルでキャッチ（例外翻訳）して、上位レベルの例外の中に包み込みます（例外連鎖）。そうすれぱ、ログなどに出力するときにも十分な情報が残されるので、不具合の原因の発見に役
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
OutOfMemoryError発生！ その解決への近道とは
これらの情報を基に、OutOfMemoryErrorの障害発生原因を探ることとなる。 障害調査～メモリ領域を切り分ける～ まずは、GCログやOutOfMemoryErrorのエラー情報から、「Javaのどのヒープ領域（Javaヒープ、Permanentヒープ、Cヒープ）でOutOfMemoryErrorになっているか」「どれだけのメモリを確保しようとして失敗したか」を確認する。 前回記事で、OutOfMemoryのエラー情報からどの領域でメモリ不足が発生しているかを見分けるポイントについては紹介した。例えば、以下のような場合には（*1）からJavaヒープでメモリが不足していることが分かる。 java.lang.OutOfMemoryError: Java heap space <=======【*1】 at java.nio.CharBuffer.wrap(CharBuffer.java:
Effective Java 読書会 13 日目 「Java の例外めんどくさい」 - IT戦記
IOException の catch に何を書いていいか分かりません＞＜！ はじめに 順番が前後しますが、今回は Java の特徴のひとつである例外機構についてです。 今回の範囲 223 ページ 〜 250 ページ 前回はこちら Effective Java 読書会 12 日目 「スレッド・セーフってなによ！！」 - IT戦記 Java の例外 throw 可能なオブジェクト Throwable インタフェースを実装したもの Exception を継承しない Throwable は基本的に使わない チェック例外 メソッドの実装者が「呼び出し元が回復可能」だと考えている例外 ちゃんと「なぜ、例外だったのか」理由が提供されるべき 呼び出し元は try catch で囲むか throws 宣言を書く必要がある Exception を継承していて RuntimeException を継承していな
Effective Java 読書会 10 日目 「Java の基本テクニック集」 - IT戦記
はじめに 読書会に参加していないところがあるので、そこは議事録を読みながら、なるべく自分の言葉で書いていきます！ 読んだところ 175 ページ〜 222 ページ 前回はこちら Effective Java 読書会 9 日目 「Enum の拡張とアノテーション」 - IT戦記 引数の検査をきちんとして javadoc の @throws に書く IllegalArgumentException IndexOutOfBoundsException NullPointerException などは、事前に引数チェックして出す。たとえば、 OpenJDK の String(byte[], int, int, String) では、以下のような実装になっている、自分で引数チェックをして、その内容を明確に @throws に記述している。 // チェック関数 private static void c
非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS
まず、以下に持論を展開するにあたって、自分の立ち位置を明確にしよう。自分は「Webアプリケーション開発者」としてではなく「JavaによるWebアプリではない（デスクトップアプリ,コマンドラインアプリ,ライブラリ）アプリの開発者」として語る。まぁ、自分に一番馴染みの深いプロダクトとしてJiemamyが挙げられるわけだが、こいつはWebアプリじゃない。Eclipse上で動くアプリケーションであり、そしてMaven2によって呼ばれるCLIアプリでもあり、また、クラスライブラリである。 この視点からJavaにおけるチェック例外と非チェック例外の話を再び。 Javaにおけるthrows句は、メソッドシグネチャの一部であり、インターフェイスにも現れる情報である。今まで「Javadocは仕様だ」と言い続けて来たが、正確にはインターフェイス（シグネチャ＋Javadoc）が仕様だ。*1 検査例外が使いにくい
例外の再考 - かとじゅんの技術日誌
愛する部下の一人がよいエントリを書いてくれたので、私も重い腰をあげてみたw Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS 短時間で、ようまとめたなーw チェック例外は、Java以外の言語では聞いたことがないのですが。Javaが10年やってきて、これがベストプラクティスなら他の言語にも存在してもよいはず。なぜ使わないんだろう。。。ということで、例外を再考してみました。 例外をめぐる議論 何気にいろいろ調べていたら、こういうのがでてきました。2004年以降はRTE使っているよというのがこれか！？ Javaの理論と実践: 例外をめぐる議論 これはもう過去にされていた議論ですね。知らなかったですw Sunは、文書化されない例外は投げるべきでない。つまるところ、扱う例外はメソッドのthrowsにちゃんと明記する派。APIを使う側のユーザとし
Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS
1st Seasonはこちら。Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS 以前は、何かをスローする状況を3つに分けてそれに合った設計をした例外を投げましょう、という考え方を示しました。 callerのバグ: RTE calleeのバグ: Error どちらでもない: Exception (非RTE) まぁ詳しくはSeason1の方で。 Seasar2はRuntimeExceptionですね。2004年ぐらいからのフレームワークはRTEをスローしていると思いますよって、ひがさんから情報。 チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌 ただ、上記のような考え方もあるのも事実。実際.NETやRuby, Python, 新鋭のScala等もcatchを強制する例外というものが言語仕様的に存在しません*1。逆に、チェック例
ダイコン時代の設計手法 - 例外処理 - ひがやすを技術ブログ
例外処理は、throwする側とcatchする側に分かれますが、 最初はcatchする側について。 catch禁止。間違いない。 個々の開発者に例外をcatchさせるとろくなことにならないというのが、 私の経験則。 例外は、原則、サービス層でcatchすることなく プレゼンテーション層に返して、プレゼンテーション層の フレームワークに処理させた方が良いでしょう。 もちろん例外はあります。 業務ロジックを大きく分類すると ユースケース個別 共通 データアクセス に分かれますが、catchを禁止するのは、ユースケース個別のものです。 catchして行いたい処理は、 ログを書く 再throwする 業務ロジックを再実行する 別の例外に変換してthrowする 等が考えられますが、これらはcrosscutting concernである 可能性が高い。そうAOPの登場です。 http://homepage
Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer