例外に掛かる処理コストについてint.Parseとint.TryParseを使って比較調査を行ってみました。 入力された文字が数字か否かを判断する方法として、数値ではない場合に例外を発生させるint.Parseがあります。 private bool IsNumericByException(string test) { try { int.Parse(test); } catch (FormatException ex) { return false; } return true; } もうひとつ別のバージョンとして、数値ではない場合にFalseを返すint.TryParseがあります。 private bool IsNumericByTryParse(string test) { int a; return int.TryParse(test, out a); } この２つの処理をそれぞ
概要 [2012-11-24] 例外一覧 [/2011-07-30] 例外の基礎 [/2011-06-25] チェック例外 [2012-11-24] NPEのメッセージ [/2020-09-29] 例外とは Javaでは、プログラム実行中に異常事態が発生してそれ以上正常に実行できない場合に、“例外（Exception）”と呼ばれるオブジェクトを作成し、メソッドの呼び出し元に渡す（返す）ことが出来る。[2012-11-24] つまりJavaで言う「例外」とは、一般的な文章で使う「それは例外事項だ」「通常ではない」というようなニュアンスではなく、「Exception」（というクラス・オブジェクト）を表す名詞（専門用語）である。 メソッドでは 処理が正常に終わる場合はreturn文によって値を返すが、例外オブジェクトを返す場合はthrow文という専用の構文を使う。 「throw」は「投げる」とい
ささやかなお正月飾り お正月飾りに葉牡丹の寄せ植え。関西は色々な葉牡丹が揃っていて選ぶのも楽しい キンセンカ ブロンズビューティー この後、門扉のそばに飾りました。華やかになりましたね そしてしめ縄作り。 松、水引き、しめ縄に庭の南天を加えました あわじ結びから、固く結ばれた…
SAStrutsでエラーメッセージを設定してエラー画面に遷移する方法 2
前回のSAStrutsでエラーメッセージを設定してエラー画面に遷移する方法だと記述量が多いので扱いにくい。 static importや可変長パラメータを使用して書きやすくしてみた。 ユーティリティクラス import org.apache.struts.action.ActionMessage; import org.apache.struts.action.ActionMessages; public class AppUtil { public static ActionMessages getErrors(String msgKey, String ...args) { ActionMessages errors = new ActionMessages(); errors.add(ActionMessages.GLOBAL_MESSAGE, new ActionMessage(m
SAStrutsのページには例外処理はstrutsのもともとの機構を使ってね。http://sastruts.seasar.org/featurereference.htmlとかかれているが、まぁどうせならstruts-config.xml触りたくないのでインターセプターを作ってみた。 public class ForwardThrowsInterceptor extends ActionMessagesThrowsInterceptor { private static final long serialVersionUID = 1L; public String globalForward; public String noRoleForward; public String handleThrowable(Exception e, MethodInvocation invocatio
SAStrutsで、例外発生時にエラーページに遷移させたい。 これが今回やりたいこと。どうやらStrutsの機能でできるようです。以下はリファレンスの引用です。 struts-config.xml <global-exceptions> <exception path="/error/norole.jsp" key="errors.norole" type="org.seasar.struts.exception.NoRoleRuntimeException"/> </global> Super Agile Struts - Feature Reference これを参考に、struts-config.xmlに以下のように記述。実行時例外が対象です。 <global-exceptions> <exception path="/error.jsp" key="errors.system" t
1st Seasonはこちら。Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS 以前は、何かをスローする状況を3つに分けてそれに合った設計をした例外を投げましょう、という考え方を示しました。 callerのバグ: RTE calleeのバグ: Error どちらでもない: Exception (非RTE) まぁ詳しくはSeason1の方で。 Seasar2はRuntimeExceptionですね。2004年ぐらいからのフレームワークはRTEをスローしていると思いますよって、ひがさんから情報。 チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌 ただ、上記のような考え方もあるのも事実。実際.NETやRuby, Python, 新鋭のScala等もcatchを強制する例外というものが言語仕様的に存在しません*1。逆に、チェック例
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
愛する部下の一人がよいエントリを書いてくれたので、私も重い腰をあげてみたw Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS 短時間で、ようまとめたなーw チェック例外は、Java以外の言語では聞いたことがないのですが。Javaが10年やってきて、これがベストプラクティスなら他の言語にも存在してもよいはず。なぜ使わないんだろう。。。ということで、例外を再考してみました。 例外をめぐる議論 何気にいろいろ調べていたら、こういうのがでてきました。2004年以降はRTE使っているよというのがこれか！？ Javaの理論と実践: 例外をめぐる議論 これはもう過去にされていた議論ですね。知らなかったですw Sunは、文書化されない例外は投げるべきでない。つまるところ、扱う例外はメソッドのthrowsにちゃんと明記する派。APIを使う側のユーザとし
C#3.0からはvarと書くと型を明示的に指定しなくても済む。 var hoge = new HogeClass(); しかし例外処理をするためにこれをtry〜catchで囲みたいとする。 try { var hoge = new HogeClass(); hoge.XXX(); } catch { if (hoge!=null) hoge.YYY(); } このプログラムはコンパイルが通らない。catchのなかでは変数hogeにアクセスできない。try節が終わっているため、hogeのスコープが終わってしまうのだ。仕方ないのでhogeを外部のブロックに出す。 var hoge; try { hoge = new HogeClass(); hoge.XXX(); } catch { if (hoge!=null) hoge.YYY(); } しかしこれまたコンパイルが通らない。var hog
例外ハンドリング時に考えた色々な事についての備忘録。 使用バージョン：Ver1.7.8 http://framework.zend.com/download/current/ ZFのダウンロードはこちら ZFにおける例外発生時の処理 ZFはPHP5ベースなので、何か問題が発生した時は例外をスローして対応する仕様となってます。 デフォルトの状態では例外がスローされると、Zend_Controller_Plugin_ErrorHandler.phpを経由してErrorController.phpに処理が委譲されます。 ErrorController.phpの基本的な書式はZFのマニュアルページにあります。 http://framework.zend.com/manual/ja/zend.controller.plugins.html 具体的には以下のような感じです。 <?php class E
Zend Frameworkマニュアルに記述のあるエラー処理について紹介します(7.10.5.2節参照)。ソースコードはこちらからダウンロードできます。 <?php class ErrorController extends Zend_Controller_Action { public function errorAction() { $errors = $this->_getParam('error_handler'); switch ($errors->type) { case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER: case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION: // 404 error -- controller or
例外ってなに? プログラムを書いていると、try ... catch を書くのがめんどうになったことはありませんか。 たとえば、リスト 1 はファイルを読み込んで単に標準出力に出力を行うプログラムです。これを javac でコンパイルすると、図 1 のようにコンパイルエラーが起きて、コンパイルできません。そこで、「しょうがない、try ... catch を書くか」といって、リスト 2 のように書いたとします。「これでコンパイルはできたから OK」と済ませていませんか。 これでは例外から得ることのできるさまざまな有用な情報を捨ててしまっています。それだけでなく、想定していた動作を行うことができないかもしれません。 逆にいえば、例外を有効に使いこなせるようになれば、プログラムの堅牢性を高めることができ、また保守性も向上させることが可能です。そんな例外の基本から例外を使いこなす
例外をキャッチしたときにしたいこと ログ取り エラー画面の表示 なので、Exceptionクラスを拡張して、上の2つのメソッドを追加する。 ・exception.php <?php /* */ class My_Exception extends Exception { protected $error_message; protected $template = "errors/500.phtml"; public function __construct($message, $code=0) { parent::__construct($message, $code); // $this->logging(); $this->display(); } public function logging() { $this->error_message = $this->createMess
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
