Java 歴 23 分の Ruby エンジニアが Effective Java を読んで感動した話 - scramble cadenza

イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか？ どの例外をキャッチし、どの例外を伝搬させればよいだろうか？ 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか？ 例外をどういう単位でラップさせるのが良いだろうか？ 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja

[snowcrush]

例外で状態チェックをするのはRubyでよく使われるやり方だし一概にダメとは言えないんじゃないかな。他の言語のやり方を知っておくのはいいことだけど、Javaの場合Java自身に依存した独特な技法が多い気がする。

[alex0715]

Effective Java、本棚に綺麗な状態で眠ったままだ。

[jukuringo]

チェック例外は個人で使いたいなら使ってもいいけど、業務コードからは出来る限り排除したい感ある。使用者の理解度に依存したスパゲッティを生み出してしまうようなイメージがあるし。

[kjw_junichi]

Java以外の限度でどの程度通用するのかが気になる

[komz]

Java 歴 23 分の Ruby エンジニアが Effective Java を読んで感動した話

[Nilfs]

回復可能な例外とそうでないものがあるのは、Javaの言語デザインから来る運用例だと思ってたけど、この分け方が安定しそうなのかな

[takohaka]

try~catchはパフォーマンスが下がる。

[onefootinthegrave]

やっぱチェック例外は炒らない子だとおもうなあ。