2017/10/02 11:19:40
Pinon3s
“vimで日本語入力に切り替えるのがしんどい”
2017/10/02 13:21:32
ktanaka117
わかる
2017/10/02 13:24:59
garage-kid
85
2017/10/02 13:51:23
otihateten3510
何気に未だベストプラクティスっぽいものがない気がする。バラつきがある
2017/10/02 13:58:37
longroof
“vimで日本語入力に切り替えるのがしんどい”なぜなのだ(´・ω・｀)…
2017/10/02 14:01:47
mkataigi
具体的な方法論じゃないんだけど、エラーメッセージは「そのエラーをどうやって直すか」を考えるといいよ。ユーザに出すものはユーザが解決するためのヒントを出す、開発者が見るものは開発者が修正するヒントを出す
2017/10/02 14:08:55
n314
ユーザーが見るエラーメッセージはプログラマーがその場の思い付きで決めて良いものではないと思っている。解決策は特に無いが。
2017/10/02 14:30:05
vac201
最初にユーザーが見るかdeveloperが見るかで分けて考えるのは良くないと思うなー。そこはVBみたいに見る人が見たらわかるでいいと思う。
2017/10/02 14:55:40
weep
えらーそうなメッセージにすればいい？
2017/10/02 15:24:02
ysksy
開発方に運用の経験がないとなかなかフィードバックされずに運用のヘイトが溜まっていくやつだ。エラーログ見ても何もわからず呪詛を唱えながらソースを追いかける羽目になるよね。
2017/10/02 15:30:05
xlc
エラーメッセージとログは別物であり、それは仕様の一部。プログラマが自由に決める類のものでないのでは？
2017/10/02 15:35:14
psfactory
良いエラーメッセージの書き方 - Qiita
2017/10/02 15:41:34
efcl
開発者向けのエラーメッセージとユーザー向けのエラーメッセージについて
2017/10/02 15:59:41
ewiad420
ユーザが見るエラーメッセージって、実際にアプリケーション使っている時に画面に出てくるもので、開発者が見るのはエラーログ、ということでいいのかな？どっちでも「エラーが出ました」だけとか論外
2017/10/02 16:02:40
perl-o-pal
null pointer exception
2017/10/02 16:08:08
orenonihongogayabai
開発者向けのエラーログの注意事項としては個人情報。バリデーションエラーの詳細を残し始めるとクレカのセキュリティコードまで残すとかいうヤベーシステムが出来がちなので取捨選択を必ず行う事。
2017/10/02 17:18:12
rti7743
エラーとは本来予定してしない分岐である。よって、なぜそのエラー分岐が発生したかがわかるものが必要。あとは大抵の処理系は未処理例外をスタックトレースとともにログに落とす機能があるからそれで落とせばいい。
2017/10/02 17:31:37
lbtmplz
OKの例の素敵さ。そしてその珍しさ…
2017/10/02 17:33:16
theatrical
良いエラーメッセージはなぜかがわかるもので、すごく良いエラーメッセージはどうすれば良いかがわかるものだと思っている
2017/10/02 17:54:25
frkw2004
ユーザー向けエラーメッセージで抜けてる視点がある。エラーメッセージは画面キャプチャなり、文章なりでサポートへ送られるので、同時にログファイルに書き出すなら関連付けておく事。
2017/10/02 18:15:28
H7kayama
めも
2017/10/02 18:29:35
l__LINE__l
メモリがwrittenになることはできませんでした
2017/10/02 18:30:32
indication
最近見出だした結論は、ログであってもリソースにする+コメントで引数を明示する。例外を含む場合はスタックトレースなどすべて含む引数と例外メッセージのみの引数を定義すること。不用意な文字列結合を避けれる
2017/10/02 18:52:52
sjn
ユーザーにみえるエラーはユーザーフレンドリーなデザインの一部なんだからユーザーがどうすべきか分かるもの、エラーログはデータ仕様として解析、監視、集計に役立つものでないとという感じかな…普通の事になった
2017/10/02 19:08:43
aquos12345
臭いエラーメッセージの書き方。「何かが起こった。過ぎた事は忘れよう。」
2017/10/02 19:18:23
i_amai
ウチは組込み系だけど、ユーザーが見る最低限のメッセージに番号振って、その番号を別のエクセルの表(簡易的なマニュアルみたいなもの)で検索かけて詳しい内容を調べたりしてるな…他の会社どうやってるのか気になる
2017/10/02 19:57:04
ardarim
ユーザ向けは起きたことの外形的説明とリカバリーの方法。プラス問い合わせに備えて内部エラーコード（攻撃の機会にならないようヒューマンリーダブルでない数字の羅列）があればほぼ完璧だと思う
2017/10/02 20:07:47
slkby
「不明なエラーが発生しました」「internal server error」「Oops!」
2017/10/02 20:07:58
kenzy_n
【おきのどくですが　ぼうけんのしょは　きえてしまいました】
2017/10/02 20:27:52
reijikan
時間に追われていると、真っ先におろそかにしてしまうところ。
2017/10/02 21:01:30
kitadon
基本だけどやろうとするとできないやつや。
2017/10/02 21:50:25
jiro68
エラーメッセージで何を伝えたいのかによって含める情報は変わってくる。クラッカーにシステムの詳細情報を教えてやる必要は無い。
2017/10/02 22:32:37
slash_01
あとは Severity Level だね。これも間違えると色々面倒。
2017/10/02 23:24:21
hinaloe
ブコメ読んで理解したけど使用設計の話だったのね、なるほど
2017/10/02 23:24:33
spam_lover
現実、どっちつかずで悩むポイントのテクニカル的なアドバイス皆無で原理主義なんて役に立たねーよな。そんなもんワカットルって話でしかない。
2017/10/03 02:53:54
winger14
一方、良くない例。 “an error occurred.” 「うん、それはわかってるよ」
2017/10/03 02:54:56
fb001870
なにが悪かったのか、どうすればいいか
2017/10/03 07:13:29
uturi
「おおっと！何かが起きたようです！」というエラーメッセージを見て殺意を湧いたことあるので、とても納得できる記事。
2017/10/03 07:40:45
Rinta
エンドユーザーが見るものはなんでエラーなのかとこれからどうすればいいのか。開発者が見るものは判断の条件と値をそれぞれ出力するのがスタートラインだと思ってる。
2017/10/03 08:51:43
sai0ias
エラーメッセージってUX面で非常に大事なんだよね…エラーってそれだけでストレスだからそのフォローが下手だともっとイラつかせてしまう
2017/10/03 09:42:36
deep_one
私が後悔したのはなにより「エラー番号をつけなかったこと」だ。文章で書いたら複数箇所で同じになってた。適当につけてたら番号が被っていたことも…
2017/10/03 09:48:58
ln_north
異常系は企画やデザイナーでは予想しにくい部分もあるから、ポリシーを決めるのが一番いいな。
2017/10/03 10:48:55
aaa1234567
"vimで〜がしんどい"とか言うと、vim警察に補導されるぞ。
2017/10/03 11:03:43
su_zu_ki_1010
設計者がいかに使う側の立場になってエラーメッセージを考えられるか、がキーだよなぁとはてぶコメントも読んで思った。受託であれば、客先の担当者ともすり合わせが必要。その上で、プログラマにこう書いてと頼む。
2017/10/03 13:44:06
mixvox-j
内容は分かるがメッセージとログを一緒に取り扱っているようにも感じた。
2017/10/03 21:57:10
akabekobeko
英語だと分かち書きされるため検索するのに便利だし、API や技術用語はおおむね英語なのもあって開発者に向けたメッセージは英語のほうがよいと思う。
2017/10/04 11:07:21
amazedkoumei
ブコメが固い