IOException の catch に何を書いていいか分かりません＞＜！ はじめに 順番が前後しますが、今回は Java の特徴のひとつである例外機構についてです。 今回の範囲 223 ページ 〜 250 ページ 前回はこちら Effective Java 読書会 12 日目 「スレッド・セーフってなによ！！」 - IT戦記 Java の例外 throw 可能なオブジェクト Throwable インタフェースを実装したもの Exception を継承しない Throwable は基本的に使わない チェック例外 メソッドの実装者が「呼び出し元が回復可能」だと考えている例外 ちゃんと「なぜ、例外だったのか」理由が提供されるべき 呼び出し元は try catch で囲むか throws 宣言を書く必要がある Exception を継承していて RuntimeException を継承していな
SAStruts | 19:46画像ファイルといっても、ここで扱うのはたとえばシステムのヘッダー部分に表示するロゴ画像とか、新着情報にくっつける"New!"画像とか、背景に使用するタイル画像とかではなく、システムで扱う情報としての画像（・・というべきでしょうか）です。例えば次のようなものを想定しています。従業員情報を扱うシステムでの、従業員の顔写真購買システムなどでの商品の写真ユーザーが撮った写真（システムにアップロードしたとして）その他、システム内でユーザーが共有する情報としての画像 ではたとえば、ある従業員Ａさんの顔写真のファイル名が"A_face.jpg"だったとして、こんな感じで画面上に表示したらどうでしょう。 ブラウザーの画面上には問題なく顔写真が表示されるでしょう。でも例えば次のような問題があります。 顔写真の画像ファイルそのものに対する認証・承認をつけにくいログイン機能やアク
Domaでは、Daoのメソッドに期待されない引数（nullとか）が渡された場合に例外をスローしますが、そのときの例外にNullPointerExceptionやIllegalArgumentExceptionを使っていません。代わりに、DomaNullPointerExceptionやDomaIllegalArgumentExceptionといったDoma独自の例外を投げます。 これはなぜかというと、Daoのメソッドに対する事前条件を満たしていないのか、それともDoma自身にバグあって例外がスローされてしまっているのをわかりやすくするためです。 つまり、DomaNullPointerExceptionやDomaIllegalArgumentExceptionがスローされるということは、「これはDomaが意図的にスローしています。なんらかの条件を満たしていません。」というメッセージです。そし
2010年02月24日22:34 カテゴリGoogle App Engineサイト構築 GAE/Jで運用中に発生する例外（と一部対処法） App Engineでのアプリケーション実行中に私が遭遇した不測の例外やエラーについて、原因と（一部のみですが）対策を書いてみます。 あくまでも個人的な経験に基づくもので、多分に推測を含みますが、多少ともお役に立てば幸いです。例外の種類は随時追加したいと思います。コードの誤りや、よりよい対策などがあれば、お知らせ頂ければ幸いです。 今回記述した例外、エラーの種類 DatastoreTimeoutException ApiProxy$UnknownException ApiProxy$CapabilityDisabledException GCacheException DeadlineExceededException ConcurrentModific
例外考察シリーズ。 オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ 契約書に捨印を押す - オブジェクト指向と型システムの狭間で例外を考える その2 - プログラマーの脳みそ try-catch方式・ハンドラ方式 - オブジェクト指向と型システムの狭間で例外を考える その3 - プログラマーの脳みそ 前回はプログラム言語の例外処理機構としてtry-catch方式の他に、ハンドラによる例外処理方式を考えることができる、という話をした。「考えることができる」がこの2010年現在にそういった例外処理機構をもった言語があるかというと僕は寡聞にして知らない。ああ、僕は本当に寡聞なのでただの無知の可能性のほうが高い。メジャーどころではなさそうなんだけどどうだろう。 プログラム言語の機能として、という話だと、プログラム言語を作ろうという人とか、あるいは将来にハンドラ式の例外処
オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みその続き。 僕は不勉強なのでメイヤー氏の思想というものをそれほどトレース出来ていない。だから開放閉鎖原則についての哲学のようなもの、というのはデザインパターンから嗅ぎとったもので、誤りがある可能性が高いということをあらかじめ断っておく。間違いは指摘してもらえると嬉しい。 検査例外は開放閉鎖原則に反しない まず、検査例外は発生したその場、もしくは直接の呼出し元で処理しない限り、throws に記述せざるを得ない。 そうしない場合、より上位層の throws を追加する必要が出てくる。このような追加、もしくは変更は、中間のクラスの再リリースという手間も必要となる。 これは、明らかに開放閉鎖原則に違反する。 例外について色々と考えてみた - ぐるぐる～ 「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」につい
検査例外はアジャイルやオブジェクト指向の考えに反するという事実 - じゅんいち☆かとうの技術日誌 タイトルは釣り度が強すぎかなー、、、まぁ、個人のブログなんで気にしないでくださいw ブログはカジュアルに書けばいいんですよ。タイトル付け失敗してもサーセンです。 「オブジェクト指向の考え」ではなく「オープンクローズド原則」に反するとしたほうがいいですね。 しかし、貶める気もない人に 貶めるという定義付けは いただけないなー。 で、そんなこんなで重量級をゲットしてもた。。 非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ エントリをいただいたので、さらにまた考えてみました。 チェック例外の正当性を再検証する 最近、多くの人の尊敬を集めているBruce EckelやRod Johnsonといった
「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤解あり - じゅんいち☆かとうの技術日誌のあんまりな釣りタイトルにやれやれだぜ、と思いつつも非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESSでツッコミたかったことが突っ込まれてしまってるので、しょうがないのでオブジェクト指向と型システムの話でもしよう。 Javaの静的型システム ≠ オブジェクト指向 僕が10年ほど前、Javaを使い始めてからしばらくたってやっとオブジェクト指向プログラミングが掴めて楽しくなってきた頃合、これこそがオブジェクト指向なのだと誤解をしていたころ、オブジェクト指向は型がチェックできてなんぼだと思ってた。 javascriptのプロトタイプ型のオブジェクト指向に憤り、「あんなものはオブジェクト指向ではない」などと思うのがJavaプログラマ的中二病というやつだが
検査例外が非検査例外より安全だなんて神話だと思う。 で、なぜ C# に検査例外の仕組みがないのか……に関してはいろんな理由があるそうなのですが、一つの大きな理由は、CLR の多言語対応のためだとか。確かに C# や VB などは、言語仕様に検査例外の仕組みを導入することもできたと思うのですが、COBOL などをはじめとする言語では、言語仕様に検査例外の仕組みを導入することが難しいのは確か。 それはそうと。 「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤解あり - じゅんいち☆かとうの技術日誌 非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS オブジェクト指向と型システムの狭間で例外を考える - プログラマーの脳みそ 例外処理について、私はこう思う - プログラミング言語を作る日記 非検査例外に萌えるわけ - じゅんいち☆かとうの
愛する部下の一人がよいエントリを書いてくれたので、私も重い腰をあげてみたw Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS 短時間で、ようまとめたなーw チェック例外は、Java以外の言語では聞いたことがないのですが。Javaが10年やってきて、これがベストプラクティスなら他の言語にも存在してもよいはず。なぜ使わないんだろう。。。ということで、例外を再考してみました。 例外をめぐる議論 何気にいろいろ調べていたら、こういうのがでてきました。2004年以降はRTE使っているよというのがこれか！？ Javaの理論と実践: 例外をめぐる議論 これはもう過去にされていた議論ですね。知らなかったですw Sunは、文書化されない例外は投げるべきでない。つまるところ、扱う例外はメソッドのthrowsにちゃんと明記する派。APIを使う側のユーザとし
1st Seasonはこちら。Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS 以前は、何かをスローする状況を3つに分けてそれに合った設計をした例外を投げましょう、という考え方を示しました。 callerのバグ: RTE calleeのバグ: Error どちらでもない: Exception (非RTE) まぁ詳しくはSeason1の方で。 Seasar2はRuntimeExceptionですね。2004年ぐらいからのフレームワークはRTEをスローしていると思いますよって、ひがさんから情報。 チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌 ただ、上記のような考え方もあるのも事実。実際.NETやRuby, Python, 新鋭のScala等もcatchを強制する例外というものが言語仕様的に存在しません*1。逆に、チェック例
さて、異論、奇抜論を唱えてみようかと思っているじゅんいち☆かとうですw Clean Code アジャイルソフトウェア達人の技 作者: Robert C. Martin,花井志生出版社/メーカー: アスキー・メディアワークス発売日: 2009/05/28メディア: 大型本購入: 27人 クリック: 848回この商品を含むブログ (66件) を見る 非チェック例外の章から紹介。 C#にはそもそも言語仕様としてチェック例外がない。C++にもない。Ptyhon, Rubyにもないが堅牢なアプリケーションが実装できる。後に登場した言語ではチェック例外がないことをよく考えてくださいとw。 デメリットとしてはキャッチから例外をスローするメソッドの間でオープンクローズド原則に違反してしまうことだそうだ。つまり、throwsのことを言及しているようです。これはアプリケーションが変更に対して弱くなりがちで、t
Javaで、ちょｗｗｗ - よねのはてなに影響を受けて。 import java.io.PrintStream; import java.io.PrintWriter; public class YaruoException extends Exception { public YaruoException(String message) { super(message); } private String getAA() { StringBuilder sb = new StringBuilder(); sb.append("\n"); sb.append(" ＿＿＿_").append("\n"); sb.append(" ／_ノ ヽ､_＼").append("\n"); sb.append(" ﾐ ﾐ ﾐ oﾟ(（●）) (（●）)ﾟo
String#equalsを使った文字列リテラルとの比較の書き方として、str.equals("リテラル")と書くのがいいか、"リテラル".equlas(str)と書くのがいいかという論争がありました。 そこで、この問題について、エラー処理の方針と絡めて考えてみようと思います。 エラー処理の方針として、エラーパッシングとエラーリカバリーという考え方があります。 エラーパッシングは、エラーがあってもそれを無視して処理を行うという考え方です。例えば音楽データの再生時に、データの一部が欠けていたとしてもそこを適当に補完を行って再生を続けるような考え方です。 人間相手の処理では、エラーによって処理が止まるよりも、それなりの対処を行って処理を続けることのほうが求められるので、ユーザーインタフェースやコンテンツのプログラムではエラーパッシングで考えることが多いと思います。 エラーリカバリーは、エラーが
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
