IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
OutOfMemoryError発生！ その解決への近道とは
この記事で分かること JavaのOutOfMemoryError発生時の対応と、原因究明のための調査方法 障害調査に不可欠な7つの情報と、GCログなどから問題のメモリ領域を特定する手法 各ヒープ領域に応じた調査手順と、メモリリークの見極め方 前回記事「調査の難しい「OutOfMemoryError」事例、5選」では、「OutOfMemoryError」に対する切り分け方法の基本と、「OutOfMemoryError」発生につながる危険なケースを具体例を挙げて解説した。 今回は、その「OutOfMemoryError」の対応・調査方法を系統立てて解説する。 システムの回復が必要な場合を確認 OutOfMemoryErrorによるメモリ障害が発生すると、標準出力にOutOfMemoryErrorのメッセージが表示される。そして、JavaVMは空き領域が枯渇している中でGCを実行することになり、
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