Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性
参考 PHP公式：例外 PHP定義済み例外 Exception すべての基底となる例外クラス。 PHPはException型以外のオブジェクト、値をthrowできません。 javascriptが異常なだけです。 ErrorExcetption エラー例外。 変換用ロジックはこちら function exception_error_handler($errno, $errstr, $errfile, $errline ) { throw new ErrorException($errstr, $errno, 0, $errfile, $errline); } set_error_handler("exception_error_handler"); protected $severityでエラー番号が取得可能とか。 SPL例外 LogicException ロジック内部でのエラーを表す例外。
Golang の defer 文と、それにまつわる panic/recover 機構について調べたので、その内容を書き残しておくことにする。 Golang では defer 文を使うことで、それを呼び出した関数が終了する際に実行すべき処理を記述することができる。 例えば関数の中でオープンしたリソースを確実にクローズするために使われたりする。 試してみよう まずは、シンプルなサンプルコードを使って defer 文の動作を確認してみることにする。 内容的にはメッセージを標準出力に出すということしかやっていない。 ただし、片方には defer が付いていて、もう片方には何もついていない。 コードの記述順序的には "End" のメッセージが先に来ているが、実行するとどうなるだろうか。 package main import ( "fmt" ) func helloworld() { defer f
PHPカンファレンス福岡2017の登壇資料です。
例外をどのような状況に投げるかもしくは投げないか、というのはわりと意見が分かれるところです。もちろん、プログラミング言語によっても異なりますが、同じプログラミング言語ユーザ同士でも様々です。 基本の考え方 ベースとしては、Effective Java の項目 39 にある下記の方針が参考になります。 例外的な状況の時にのみ例外を使う。 Effective Java 禅問答のような定義ですが、これには異論は無いでしょう。例外を正常フローで利用したり、制御構造に用いるべきではありません。 人によって異なるのは「例外的な状況」の解釈です。 例外的な状況 この「例外的な状況」の解釈は人によって異なるようで、これまでも議論になっていました。これまで聞いた解釈を乱暴に分けると以下の 2 パターンに分かれます。 1. アプリケーションから独自の例外を投げる派 ランタイムやミドルウェア連携などプラットフォ
定義済み例外とSPL例外 PHPにはPHP本体が持つ定義済み例外とPHPに標準でバンドルされるStandard PHP Library(SPL)の例外のSPL例外の2種類の例外があります。SPLは標準で組み込まれるのでPHPの機能として標準的に使うことも可能ですが、マニュアルでも個別のページを持っています。 定義済み例外 SPL例外 SPL例外 SPLの作者はPDOなど多数のパッケーのleadを務められているMarcus Börgerさんです。(PECLサイト参照 https://pecl.php.net/user/helly) MarcusさんがSPLのために作成したスライドStandard PHP Libraryから例外の部分を２つ抜粋します。 「守るべき３つのルール」 例外は例外の時に使用する (Exceptions are exceptions) 制御構造のために例外を用いない (
（2015/07/02追記：PHP 7.0.0alpha2に合わせて修正しました） PHPのエラーは、エラー文言を表示するだけの警告・注意と、その場で処理を終了してしまう致命的エラー（fatal error）の2種類に大別できます。 ところで、PHP5の致命的エラーには不便な点があります。それは、set_error_handler()やその他の方法でエラーハンドリングできず、必ず終了してしまう点です。これでは致命的エラーをユニットテストするのも不便ですし、ReactPHPのようにサーバ動作させるようなプログラムも安心して使えません。 PHP7では致命的エラーが例外として実現されるようになり、エラーハンドリングの自由度が格段に上がりました。この変更の概要を紹介します。 例外のクラス階層の変更 まず、PHP7で例外クラスの階層がどう変わるかを説明します。PHP5までの例外のクラス階層は次のよう
Immutableって‥ AndroidでBitmapにグラデーション等のフィルタを適用しようと思ったところ、ImmutableなBitmapを変換する箇所でメモリの問題にぶち当たったので調べてみました。 まずは例外を。BitmapFactory でオプションを与えずにデコードした場合、生成されるBitmapはImmutable（不変）になっています。 これを… Canvas canvas = new Canvas(bitmap); canvas.drawRect(...); なんかした場合、java.lang.IllegalStateException: Immutable bitmap passed to Canvas constructor と言われChaiMaxx ImmutableなBitmapがCanvasのコンストラクタ引数に設定されている（Canvasに設定＝編集するのにI
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
