アカウント名:
パスワード:
Java の getうんたらsetうんたらは、一体なんなのであろうか。無意味なコードがただ増えるだけだ。たぶん、アクセサメソッドには、重要な価値があると信じられた時代があったのだろうが、しかし、今となっては、くだらない役立たずなのは明らか。じっさい、今出てきてる新しいプログラミング言語には、そのようなものは無い。
べつに Java で public インスタンス変数使ってコード書いても、コンパイルエラーが出るわけじゃなし。かまやしないのだが、API がそうなってないから、自分のコードだけそうするってのも少し格好わるい。
メソッドの後ろにつけられた throws IOException とか throws ParseException も、あれが困りものだ。必ず catch して何かをしなきゃいけないと決められてもらっても、無視したいものは無視するし、catch したいとなったら、RuntimeException だろうとなんだろうと、try catch 構文を書く。あれのせいでインデントは深くなるし、コードは長くなって読みにくくなるし、なんなんだあれは。
あれ、割ときっちり考えられてたりもするので侮れない。
マルチスレッドでIO処理を書いたりするとよく分かる。例外を投げうるメソッドを呼ぶ自作メソッドで、「いや、IOが失敗したら失敗しても良いよ、このメソッドは」というやつには、throwを付け、「このメソッドが例外で死んだらマルチスレッドの後処理が転けて辻褄が合わなくなるからcatchして…」とやって行くと、結構、過不足無く、処理忘れの例外を撲滅できて、その合理性を実感できる。そういうプログラムって、ややこしい構造になりがちなので、とても助かる。例外ハンドリングの強要が無いC#でプログラムしてると、catch残しが出てきて苦労する。
けどまあ、そんなめんどくさいプログラムは滅多にないので、普段使いだと、コンパイルオプションで全部チェックをOFFにしたくなる。
むしろ、追加の静的型チェックツールかなにかで、別途提供されるべき仕組みなんじゃないかと思う。
発生しうる例外をスーパークラスが決めるのは理不尽だと思う
interface などが、どのような例外があるのか予言するのは奇妙だと思います
検査例外は、実行時例外みたいに処理の関係上起こるものではなく、どちらかというと業務エラーなんかの仕様として起こり得る例外なので、それがI/Fに書けないというのは例外の設計がちゃんとできてないだけ。
# その割には、標準APIに「いやこれが検査例外なのはおかしいだろ」ってものが多々あるぞ?というツッコミは受け付ける。仕組みは正しいと思うが、運用があんまりうまく行われていない気はする。
Javaの標準APIは本当にボロボロで、Javaの設計者たち自身がオブジェクト指向も例外も理解してないようにしか見えないけど、それはJavaが現れた当時はオブジェクト指向も例外も誰も扱いがわかっておらず、古い時代の設計だから仕方がない部分はある。それは置いとくとして……
検査例外をきっちり使って設計していくと、#2671969が言うようにいろんな辻褄があっていく感覚は確かにある。ただ、検査例外など言語仕様に持ち込まなくても例外をシンプルに表現できるのを他の言語で知ってしまい、Javaの検査例外は複雑な割に制約が多いと俺は感じるようになってしまった。
#26
プライベートでJavaの勉強を始めた頃、なんで符号無し整数がないんだろうと思いました。業務でJavaを使うようになってしばらくした頃、なんで明示的にメモリの解放ができないんだろうと思いました。ちゃんと意味があるんですよね。
Javaはいろいろ新しい事にチャレンジした言語なんだよ。検査例外は失敗だったけどね。でもその失敗のおかげで後発の言語が検査例外を導入しなくて済んだんだ。
スーパークラスの throws は非常に奇妙だと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
言語というよりはAPIの特徴か (スコア:2)
Java の getうんたらsetうんたらは、一体なんなのであろうか。無意味なコードがただ増えるだけだ。たぶん、アクセサメソッドには、重要な価値があると信じられた時代があったのだろうが、しかし、今となっては、くだらない役立たずなのは明らか。じっさい、今出てきてる新しいプログラミング言語には、そのようなものは無い。
べつに Java で public インスタンス変数使ってコード書いても、コンパイルエラーが出るわけじゃなし。かまやしないのだが、API がそうなってないから、自分のコードだけそうするってのも少し格好わるい。
Re:言語というよりはAPIの特徴か (スコア:3)
メソッドの後ろにつけられた throws IOException とか throws ParseException も、あれが困りものだ。必ず catch して何かをしなきゃいけないと決められてもらっても、無視したいものは無視するし、catch したいとなったら、RuntimeException だろうとなんだろうと、try catch 構文を書く。あれのせいでインデントは深くなるし、コードは長くなって読みにくくなるし、なんなんだあれは。
Re:言語というよりはAPIの特徴か (スコア:3, 参考になる)
あれ、割ときっちり考えられてたりもするので侮れない。
マルチスレッドでIO処理を書いたりするとよく分かる。
例外を投げうるメソッドを呼ぶ自作メソッドで、「いや、IOが失敗したら失敗しても良いよ、このメソッドは」というやつには、throwを付け、
「このメソッドが例外で死んだらマルチスレッドの後処理が転けて辻褄が合わなくなるからcatchして…」とやって行くと、
結構、過不足無く、処理忘れの例外を撲滅できて、その合理性を実感できる。
そういうプログラムって、ややこしい構造になりがちなので、とても助かる。
例外ハンドリングの強要が無いC#でプログラムしてると、catch残しが出てきて苦労する。
けどまあ、そんなめんどくさいプログラムは滅多にないので、普段使いだと、
コンパイルオプションで全部チェックをOFFにしたくなる。
むしろ、追加の静的型チェックツールかなにかで、別途提供されるべき仕組みなんじゃないかと思う。
Re: (スコア:0)
発生しうる例外をスーパークラスが決めるのは理不尽だと思う
Re: (スコア:0)
interface などが、どのような例外があるのか予言するのは奇妙だと思います
検査例外は仕様としてのエラー (スコア:1)
検査例外は、実行時例外みたいに処理の関係上起こるものではなく、どちらかというと業務エラーなんかの仕様として起こり得る例外なので、それがI/Fに書けないというのは例外の設計がちゃんとできてないだけ。
# その割には、標準APIに「いやこれが検査例外なのはおかしいだろ」ってものが多々あるぞ?というツッコミは受け付ける。仕組みは正しいと思うが、運用があんまりうまく行われていない気はする。
Re: (スコア:0)
Javaの標準APIは本当にボロボロで、Javaの設計者たち自身がオブジェクト指向も例外も理解してないようにしか見えないけど、
それはJavaが現れた当時はオブジェクト指向も例外も誰も扱いがわかっておらず、古い時代の設計だから仕方がない部分はある。
それは置いとくとして……
検査例外をきっちり使って設計していくと、#2671969が言うようにいろんな辻褄があっていく感覚は確かにある。
ただ、検査例外など言語仕様に持ち込まなくても例外をシンプルに表現できるのを他の言語で知ってしまい、
Javaの検査例外は複雑な割に制約が多いと俺は感じるようになってしまった。
#26
Re: (スコア:0)
プライベートでJavaの勉強を始めた頃、なんで符号無し整数がないんだろうと思いました。
業務でJavaを使うようになってしばらくした頃、なんで明示的にメモリの解放ができないんだろうと思いました。
ちゃんと意味があるんですよね。
Re: (スコア:0)
Javaはいろいろ新しい事にチャレンジした言語なんだよ。
検査例外は失敗だったけどね。
でもその失敗のおかげで後発の言語が検査例外を導入しなくて済んだんだ。
Re: (スコア:0)
スーパークラスの throws は非常に奇妙だと思う。
Re: (スコア:0)