質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

Q&A

解決済

4回答

16549閲覧

エラーメッセージどこに書いていますか?

redhat98

総合スコア236

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

0グッド

3クリップ

投稿2015/04/21 03:11

業務アプリケーションではエラーメッセージを、何処に書くのがベストだと思いますか?

① javaのソースに直接書き込んでしまう
② 画面毎にメッセージファイルを作る
③ システム共通のメッセージファイルに集約する
④ その他

ソース直書きは、コードの可読性を下げるのではないかなと思います。

システムの構成は
① Android(java) + サーバサイド(java)
② HTML5 + サーバサイド(java)
の2パターンを想定しています。

人それぞれ好みがあるので宗教的な話になる気もするのですが...

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答4

0

好みもありますが、場合によってはエラーメッセージ一覧で管理するルールがあったりします。この時は一覧からプロパティーファイルを作っています。

国際化の場合もプロパティーファイルになります。

ということで、③ですね。

投稿2015/04/21 04:05

argius

総合スコア9388

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

ベストアンサー

システムの規模にもよりますが、自分が参画したプロジェクトでは大抵③でした。

メッセージ定数クラスを用意したり、
メッセージIDクラスを用意してメッセージ自体はDBに用意したり。

そうするとメッセージ一覧などの資料の管理も楽になりますし、
どのメッセージがどこで呼ばれているかがすぐにわかります。

コードに直接書くのはあまり好きではないですね。
管理できなくなるし、
別のクラスに似たようなメッセージを書いてしまう事にもなりますので。

投稿2015/04/21 04:33

runun

総合スコア305

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

redhat98

2015/04/21 10:07

>メッセージIDクラスを用意してメッセージ自体はDBに用意したり。 このクラスの実装は、定数が並べられただけのクラスでしょうか?
runun

2015/04/21 10:29

そうですね。 public const string SYSTEM_ERR_MSG = "1111111111"; public const string LOGIC_ERR_MSG = "2222222222"; public const string XXXXX_ERR_MSG = "3333333333"; って感じで。 で、そのIDでDBからメッセージを取得する。 DBでメッセージ内容を管理したい時にはこうします。
guest

0

状況によりますが、クラスごとに文字列定数を持ってしまうことが多いです。そのクラスを使いまわしたりする際に、最小限必要なファイルで済む、というのがメリットです。

プロジェクトでポリシーが決まっている場合は従います。Javaではないですが、Windowsアプリケーションなどではすべてのエラーメッセージを番号で管理して、ユーザサポートのときにユーザから報告を受けた人(非開発者)がエラー番号で発生個所を切り分けたりするようなことをよくするので。

投稿2015/04/21 04:24

KoichiSugiyama

総合スコア3041

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

開発の規模、人数にもよると思いますが、小〜中規模、少人数ならソースに書いちゃいます。
バリデーションメッセージとかどこでも使うのは共通のメッセージファイルに集約。

実際にエラーメッセージを生成するソースと遠い場所に書かれてると修正が面倒じゃないですか?
個人的なポリシーとしては「関係あるモノは近くに置く」です。

ばかでかいメッセージファイルやDBに格納してるプロジェクトもあるみたいですが
メッセージってそんなに変更発生しないし、変更があっても grep すればちゃちゃっと終わりますからね。
あんまりメリットを感じないです。

ただしi18nは除く。

投稿2015/04/21 03:53

kodai

総合スコア759

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

redhat98

2015/04/21 10:12

個別のメッセージファイルについて サーバ側とAndroid側で分かれているので、メッセージファイルをどのように配置するのがベストなのかな?って疑問がわきました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問