Javaで、やる夫www - ( ꒪⌓꒪) ゆるよろ日記
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
Javaで、ちょｗｗｗ - よねのはてな
GoogleAppEngine Javaで遊べるようになったからって変なExceptionばかり投げちゃダメですよ。 public class ChowwwException extends Exception { public ChowwwException(String message) { super(message); } } public class Test { public static void main(String[] args) throws Exception { if (true) { throw new ChowwwException("イミフｗｗｗ"); } } } Exception in thread "main" ChowwwException: イミフｗｗｗ at Test.main(Test.java:4)ダメ。ゼッタイ。
エラー処理の方針とString#equalsの書き方 - 2009-02-19 - きしだのはてな
String#equalsを使った文字列リテラルとの比較の書き方として、str.equals("リテラル")と書くのがいいか、"リテラル".equlas(str)と書くのがいいかという論争がありました。 そこで、この問題について、エラー処理の方針と絡めて考えてみようと思います。 エラー処理の方針として、エラーパッシングとエラーリカバリーという考え方があります。 エラーパッシングは、エラーがあってもそれを無視して処理を行うという考え方です。例えば音楽データの再生時に、データの一部が欠けていたとしてもそこを適当に補完を行って再生を続けるような考え方です。 人間相手の処理では、エラーによって処理が止まるよりも、それなりの対処を行って処理を続けることのほうが求められるので、ユーザーインタフェースやコンテンツのプログラムではエラーパッシングで考えることが多いと思います。 エラーリカバリーは、エラーが
ウノウラボ Unoh Labs: Javaの例外処理
ウノウでは特に最近、積極的にエンジニアを採用しています。 採用ページをご覧になり興味のある方、ぜひご応募ください！！ Find Job!でも募集開始してます！ こんにちは。中村です。 少し前になりますが、社内勉強会にてJavaの例外処理について取り上げてみました。ウノウではPHPなどのLLを使うことが多いのですが、Javaの例外処理はよくできていると思っていたので、LL言語中心の人にも参考になるかもしれないと思ったためです。社内勉強会ということで、PHPと比較して違っている点が中心になっています。 例外とは？ PHPを含め例外処理がある言語はたくさんありますが、例外を簡単に表現するとエラー検査のための方法として提供されている機構で、throwされcatchされる特徴があります。本来の動作プログラムとエラー処理を明確に分けることができて、コードが理解しやすくなったりメンテナンス性が上がっ
スレッドプール側で投げる例外に注意 - 匣の向こう側 - あまりに.NETな
http://d.hatena.ne.jp/akiramei/20060124/p1 ↑は、ちょっと説明が足りなすぎなので補足します。 using System; using System.Threading; delegate void SilverSkin (); class Program { static void Lance () { throw new Exception ("届け…"); } static void Callback (IAsyncResult r) { SilverSkin ss = r.AsyncState as SilverSkin; Console.WriteLine ("In Callback."); try { ss.EndInvoke (r); } catch (Exception) { Console.WriteLine ("例外をそのまま投げ
いまさら聞けない.NET テクノロジの例外管理の設計および実装のガイドライン その２ - Bug Catharsis
例外の検出 .NET Framework では、他の一般的な水準のオブジェクト指向プログラミング言語と同じように、 構造化例外処理を利用して例外を適切に処理することができる。 構造化例外処理とは、例外と保護されたコードブロック、およびフィルタを含む制御構造によって、 例外処理を堅牢かつ効率的に行うことができる仕組みである。 try、catch、および finally ブロックを使い、コード内で送出された例外を検出し、 ログを記録したり復旧を試みるなど、適切な対応をとることができる。 まず、例外を送出する可能性のあるコードがtry ブロックに記述される。tryブロック内で例外が送出されると、 その例外のクラスにマッチするフィルタを持つ最初の catch ブロックが例外をキャッチする。 複数の catch ブロックを置く場合には、具体的な型から一般的な型の順に並べる必要がある。 そうしなければ
いまさら聞けない.NET テクノロジの例外管理の設計および実装のガイドライン その１ - Bug Catharsis
例外管理ポリシー アプリケーションの内部で発生した例外を管理する際には、いくつか考慮すべきことがある。 まず、「発生した例外をどのタイミングで捕捉するのか」、「捕捉した例外をどのように処理するのか」、 そして、「捕捉した例外をどのように伝播させるのか」などである。 こういった例外に対するポリシーは、システムの要件や規模によって変化するのが常で、 例外管理システムを担当する設計者の思想と過去の経験などが大きく影響してくるが、 一般的にベストプラクティスとして知られる基本的なポリシーがある。 例えば、例外を捕捉するタイミングは、以下のいずれかの例外処理を行うケースが考えられる。 １．ログの記録のために情報を収集するケース ２．例外に何らかの関連情報を追加するケース ３．リソースの解放などのクリーンアップ・コードを実行するケース ４．復旧を試みるケース 逆に言えば、これらの条件に合致しないような
適切に処理されなかった例外をキャッチするには？
連載目次 Windowsフォーム・アプリケーションやコンソール・アプリケーションを実装する際、例外が発生する可能性がある個所では、基本的に、Try-Catch構文によりその例外をキャッチして適切な処置を施す必要がある。しかし現実には、例外が正しくキャッチ（＝トラップ）されていないというケースは多々あり、その場合にはアプリケーションの実行中に次のような.NET Framework標準のエラー・ダイアログが表示されてしまうことになる。 このエラー・ダイアログは、見て分かるとおり、一般的なユーザーにとって分かりやすいものとはいえない。パソコンの操作に自信のない人であれば、これを見た途端に困惑してしまうということもあるだろう。 このような事態を避けるために、.NET標準のエラー・ダイアログを、もっとユーザー・フレンドリな自作のエラー・ダイアログに切り替えたいという要望も、きっと多いのではないだろう
捕捉されなかった例外がスローされたことを知る
捕捉されなかった例外がスローされたことを知るここでは、Windowsフォームアプリケーションとコンソールアプリケーションにおいて、Try...Catch...で捕捉（キャッチ、ハンドル、トラップ）されなかった例外（エラー）がスローされたときに、その例外の情報を知るための方法を紹介します。 ただし、できるだけエラー処理はTry...Catch...（詳しくは、「エラー処理（例外処理）の基本」）を使って行うべきであり、ここで紹介している方法はどうしてもそうしなければならない時のみ使用してください。 Application.ThreadExceptionイベントを使用する方法Windowsフォームアプリケーションでは、捕捉されなかった例外がスローされるとApplication.ThreadExceptionイベントが発生します。 ThreadExceptionイベントが発生するのは、Window
What!? A .NET Application Can Die? | CodeGuru
by John Robbins of Wintellect You have to love .NET. All those nasty crash problems we used to wrestle with in Win32 are now just stories we can tell around the virtual campfire. No longer will our users have to see that ugly crash dialog telling them oh so subtly that we programmers screwed up. Life it .NET is great, isn’t it? The prior paragraph was somewhat of a dream sequence. While .NET does
java.net: Exception-Handling Antipatterns
Should you throw an exception, or return null? Should you use checked or unchecked exceptions? For many novice to mid-level developers, exception handling tends to be an afterthought. Their typical pattern is usually a simple try/catch/printStackTrace(). When they try to get more creative, they usually stumble into one or more common exception handling antipatterns. The antipattern concept became
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マルチスレッドの例外処理 - NAnduブログ
http://japan.internet.com/developer/20061212/26.html
IBM Developer