Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS
1st Seasonはこちら。Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS 以前は、何かをスローする状況を3つに分けてそれに合った設計をした例外を投げましょう、という考え方を示しました。 callerのバグ: RTE calleeのバグ: Error どちらでもない: Exception (非RTE) まぁ詳しくはSeason1の方で。 Seasar2はRuntimeExceptionですね。2004年ぐらいからのフレームワークはRTEをスローしていると思いますよって、ひがさんから情報。 チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌 ただ、上記のような考え方もあるのも事実。実際.NETやRuby, Python, 新鋭のScala等もcatchを強制する例外というものが言語仕様的に存在しません*1。逆に、チェック例
Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ
「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤解あり - じゅんいち☆かとうの技術日誌のあんまりな釣りタイトルにやれやれだぜ、と思いつつも非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESSでツッコミたかったことが突っ込まれてしまってるので、しょうがないのでオブジェクト指向と型システムの話でもしよう。 Javaの静的型システム ≠ オブジェクト指向 僕が10年ほど前、Javaを使い始めてからしばらくたってやっとオブジェクト指向プログラミングが掴めて楽しくなってきた頃合、これこそがオブジェクト指向なのだと誤解をしていたころ、オブジェクト指向は型がチェックできてなんぼだと思ってた。 javascriptのプロトタイプ型のオブジェクト指向に憤り、「あんなものはオブジェクト指向ではない」などと思うのがJavaプログラマ的中二病というやつだが
Webアプリで動的型付言語や開発管理が流行りIDEが流行らなかった理由などなど - きしだのHatena
考えてみた。 ここんところ静的型付けなんか不要な空気になってたり、プログラムの内容よりも品質だとか開発管理の話題のほうが盛んだったり、IDEはあると便利だけどなくても大丈夫って雰囲気だったりする理由。 この10年Webアプリケーション花盛りだから、その理由はWebアプリケーションの構造にあるとして考えた。 Webアプリケーションの構造 で、まずはWebアプリケーションの構造。 字が汚いけど、左からブラウザ、アプリケーション、セッション、DB。 赤文字は、左がプログラム実行、右がデータの永続と書いてある。つもり。 Webアプリケーションでは、ブラウザからのリクエストを受けて、プログラムが動き、データベースの情報を処理して返す。 ブラウザ側でプログラムが動くことはあるけど、入力補助程度であまりたいしたプログラムは書かないので、主にサーバー側のプログラムを組む。 このとき、サーバー側のプログラム
非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS
まず、以下に持論を展開するにあたって、自分の立ち位置を明確にしよう。自分は「Webアプリケーション開発者」としてではなく「JavaによるWebアプリではない（デスクトップアプリ,コマンドラインアプリ,ライブラリ）アプリの開発者」として語る。まぁ、自分に一番馴染みの深いプロダクトとしてJiemamyが挙げられるわけだが、こいつはWebアプリじゃない。Eclipse上で動くアプリケーションであり、そしてMaven2によって呼ばれるCLIアプリでもあり、また、クラスライブラリである。 この視点からJavaにおけるチェック例外と非チェック例外の話を再び。 Javaにおけるthrows句は、メソッドシグネチャの一部であり、インターフェイスにも現れる情報である。今まで「Javadocは仕様だ」と言い続けて来たが、正確にはインターフェイス（シグネチャ＋Javadoc）が仕様だ。*1 検査例外が使いにくい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
