JavaFXの例外処理ベストプラクティス

例外をむやみにキャッチして握り潰してはいけない これはよく知られている鉄則です。自ら対処できないのであれば 例外をキャッチせずに上位にそのまま伝搬させるのが良い設計であるとされています。

例外を握り潰してしまっている例
public void my​Business​Logic() { try { do​Something(); } catch(IOException e) { e​.print​Stack​Trace(); } }

この鉄則は広く浸透しており 上記のようなコードを書いている人はもういません。多くの開発者は 処理できない例外をそのまま伝搬させるコードを書きます。

例外をキャッチせずにそのまま上位に伝搬させる例
public void my​Business​Logic() throws IOException { do​Something(); }

この鉄則は 呼び出される側のコード について言及したものです。呼び出される側のライブラリならそれで十分でしょう。しかし 伝搬していった例外はいつか誰かがキャッチしなければなりません。その役回りは ほとんどの場合 アプリケーションが務めることになります。

ライブラリでは投げっぱなしにできた例外も アプリケーションではそうはいきません。投げっぱなしにされた例外をアプリケーションはどのようにハンドリングすれば良いのでしょうか?

Java​FX を例にアプリケーションでの例外処理を解説します。

SVNチェックアウトで E120104 エラーが発生したときの対処方法

先日 某社内ネットワークからインターネット上にある Subversion リポジトリのチェックアウトを試みたところ下記のエラーが発生してしまいました。サーバーは Subversion 1.9.5 クライアントは Subversion 1.12.2 でした

svn: E120104: ra_serf: An error occurred during decompression

エラーメッセージに含まれる ra_serf というのは Subversion で使われている HTTP クライアントライブラリです。この HTTP クライアントライブラリが Subversion サーバーから転送されてきた圧縮データを展開するときにエラーが発生したということです。

ウェブで ra_serf を検索してみると 上記のエラーのほか E120106: ra_serf: The server sent a truncated HTTP response body​. が発生したという報告も多数見つかります。

Javaはカレントディレクトリを使わない

Java 11 から user​.dir システムプロパティを実行時に変更することができなくなりました。この変更によって 相対パスを解決する開始点を実行時に変更している一部のアプリケーションが影響を受けます。

user​.dir システムプロパティとカレントディレクトリの関係について説明します。

IntelliJ IDEAでGradleプロジェクトの実行がエラーになる!?

Eclipse で開発していた Java​FX アプリケーション Gradle プロジェクト形式 がありました。この Gradle プロジェクトを Intelli​J IDEA にインポートして実行すると Illegal​State​Exception: Location is not set​. というエラーが発生してアプリケーションの起動に失敗してしまいました。Eclipse では実行できていたのになぜ?

その原因は Eclipse Intelli​J IDEA のリソースの扱いの違いにありました。Gradle プロジェクトでリソースをどこに配置するのがよいか紹介したいと思います。

書式化したまま編集できるテキストフィールドを作る(JavaFX)

先日 インターネットバンキングで振込操作をしたのですが ユーザーインターフェースの出来があまり良くないと感じました。振込金額の欄に 3 桁区切りのカンマが表示されず 100 万円を振り込むために 1000000 と入力する必要があったのです。

 いち じゅう ひゃく せん まん

画面の数字を 1 桁ずつ指差しながら数えて金額に間違いがないことを確認しました。一応 確認画面に進むとカンマ付きで 1,000,000円 と表示されたのですが 画面遷移するまで書式化された表示にならないのってユーザビリティとしてどうなの?

他所様のシステムに文句を言いたいわけじゃないんです。自分も同じような実装をしてきたなあと反省してしまったのです。画面遷移するまで書式化されないというほど酷くはなかったのですが…

jlinkで他プラットフォームのJREを作成する(クロス・ターゲット)

以前の記事 JRE が単体で配布されなくなった理由 では Java アプリケーションに軽量化した JRE をバンドルする配布方式について紹介しました。

従来のシステムワイドに Java をインストールする方法では 一部のアプリケーションの都合で Java のバージョンを据え置かなければならない状況を生むことがありました。1 つのアプリケーションが新しいバージョンの Java で動作検証されていない たったそれだけの理由で古い Java が使われ続けるなんてこともあったのです。古いバージョンの Java がシステムに居座り続けていると 当然 悪循環に陥ります。

 すでに Java 5 がインストールされているから新規アプリも Java 5 で作ってね!

もうこれ一生抜け出せないパターンじゃないですか…。

JavaFXアプリケーション開発にはLiberica JDKがオススメ

私はこれまで Java​FX アプリケーションの開発に Oracle Open​JDK Gluon Java​FX の組み合わせを使ってきました。JDK Open​JFX をマージするバッチファイルを作ったりもしました。

でも そんな手間を掛ける必要はなかったんです。はじめから Open​JFX がバンドルされている Open​JDK ディストリビューションを使えば済む話だったのです。Open​JFX をバンドルしている Open​JDK それが Liberica JDK です。

JettyでFreeMarkerを使うとテンプレートが見つけられなくなる

Free​Marker テンプレートエンジンを使った Web アプリケーションを Jetty アプリケーションサーバーで数日稼働させていると以下の例外が発生することがありました。

freemarker​.template​.Template​Not​Found​Exception: Template not found for name "index​.ftl".

なぜかテンプレート ファイルが見つけられなくなってしまうのです。その原因は Jetty Windows にありました。

Gradleプロジェクトの雛形をカスタマイズする

私は Java コードを書くのに Eclipse を使っています。以前はプロジェクト形式として標準の Java Project を選択していましたが 現在は Gradle プロジェクト形式を選択するようにしています。

Gradle の素晴らしさを知ったのは Android アプリケーションの開発で Android Studio に触れた折でした Android Studio のプロジェクト形式は Gradle プロジェクト形式だったのです。以来 Android 以外の Java アプリケーション開発 Web サーバーアプリや Java​FX アプリ でも Gradle プロジェクト形式を採用するようになりました。

今回は Gradle プロジェクトの雛形をカスタマイズする方法を紹介します。

Java 12に対応したexewrap 1.4リリース

Java 12 に対応した exewrap 1.4 をリリースしました。

exewrap 1.3.1 以前のバージョンで作成した実行ファイルを Java 12 で実行するとコンソールに以下の警告メッセージが表示されます。メッセージが表示されるだけでアプリケーションの動作自体には問題ありません

Open​JDK 64-Bit Server VM warning: Archived non-system classes are disabled because the java​.system​.class​.loader property is specified (value = "Loader"). To use archived non-system classes, this property must not be set

この問題が exewrap 1.4 で改善しています。exewrap 1.4 で作成した実行ファイルであれば Java 12 実行環境でも上記のメッセージは表示されなくなります。