Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この記事は bouzuya's RxJS Advent Calendar 2015 の 8 日目かつ RxJS Advent Calendar 2015 の 8 日目です。 はじめに 今日は ReactiveX の Operators の Error Handling について RxJS の API ドキュメントやソースコードを見ていきます。 また RxJS 4.0.7 を対象にしています。 Observable のエラーハンドリング subscribe (Observer) の onError 各種 Operator よりまず subscribe (Observer) の onError です。Observable.throw でエラーを流してみましょう。 import { Observable } from 'rx'; Observable .throw(new Error('ERRO
なぜTransactionが必要なのか Transationの目的は、あるいコードブロックにあるSQL文の変更を、全部成功することを守るための存在である。Transactionにより、データの統一性を保ことができる。銀行などの受け入れと引き出しの処理には必要でしょう。二つの処理の中一つが失敗すると、コードブロークにあるSQL処理を全部ロールバックされるのが、Transactionの特徴である。 Transationのロールバックが発火条件 Railsでは、ロールバックが発火するには、「例外」が必要である。これがTransactionを使うときのもっとも重要なことである。 例えば、Railsでは #update_attributeは例外を発火せずに、falseに返すとなる。そのため、#update_attributeを使うには、結果を見て、例外をスローする必要がある。Railsではびっくりマ
応用可能性の低そうなメモ。 AngularJSの$httpでは、戻り値のpromiseについて、通常のthenのほかに、success / errorを使うことができます。これはどうしてなのでしょうか?AngularJSのpromiseの隠し仕様で、戻り値の関数名を指定することができるのか、それとも隠しメソッドとして、sucess / errorを持っているのか?などと妄想が膨らんでしまいます。 そこで、AngularJSのコードを読んでみると、大したことはなく、 promise.success = function(fn) { promise.then(function(response) { fn(response.data, response.status, response.headers, config); }); return promise; }; promise.error
<?php $message = sprintf( "HTTP/%s %s %s", $response->getVersion(), $response->getCode(), $response->getMessage() ); throw new HttpException($message, $response->getCode()); <?php class HttpException extends \Exception { /** * 例外を作成して投げるメソッド * * @param $response HttpResponse * @throws HttpException */ public static function raise(HttpResponse $response) { $message = sprintf( "HTTP/%s %s %s", $resp
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性
クライアントのエラーをキャッチする この記事を読みました。 WEBブラウザで起きた JavaScript のエラーをサーバに送りたい 素晴らしいアイデアですが、AngularJSでは、window.onerrorが発火しないため、通常のやり方が通用しません、とのこと。 そのため、$exceptionHandlerという、例外を集約しているサービスをオーバーライドする必要があります。 以下のように書けば問題ないかと思われます。 angular.module('myApp') .factory('$exceptionHandler', function($injector) { return function errorCatcherHandler(exception) { // オーバーライドしたためブラウザにエラー出力しないので、ここからブラウザにエラー出力する console.error
Elixirで監視状態においたWorkerプロセスがエラーになっても, 監視プロセスが検知してWorkerを再起動してくれるという振舞を手を動かしながら試してみましょう. ElixirでTaskを使ってEchoServerを動かすという記事の一部を再構成して提供しています. Workerを作る まずはWorkerの例としてTCP/IPで接続を待ちうけるサーバーを作ります. Erlangには gen_tcp というライブラリがあるのでこれを用いてTCP/IPを扱います. :gen_tcp.xxx となっている記述の部分で利用しています. # echo_server-1.exs defmodule EchoServer do def accept(port) do # オプションは以下のような意味である: # # 1. `:binary` - データを(リストのかわりに)バイナリとして受けとる
John Bohnさんのブログ記事 Elixir Process Architecture or: How I Learned to Stop Worrying and Love to Crashの翻訳です。 Elixir(とそのベースになっているErlang)のプロセスは生成のためのコストが小さいため「下手にエラー処理するコードを書いてプロセスを維持するよりはさっさとクラッシュさせて、それに続く処理の中で対策して再起動したほうがよい」という思想があります。それを実際に適用してみたという話です。なお説明を簡単にするために多少端折ってるとのこと。 ところでこのタイトルは某古典的スラップスティックSF映画のアレですね… "クラッシュさせちまえ" それは私が聞かされ続けてきたことだ。正直言ってそのセリフの意味するところを理解するまで少々時間が必要だった。その考え方がピーンと来るにはProcess
WWDC 2015 で Swift 2.0 が発表されました。オープンソース化などのうれしいニュースでも盛り上がっていますが、言語仕様としては try, throw, catch が導入されるという大きな変更がありました。本投稿は、 The Swift Programming Language の新章 Error Handling を読み、多少のコードを書いた上での個人的な感想です。 結論から言うと、 try, catch の導入は良い変更だと思えないけど、 try, catch を導入する前提なら考え得る限りベストに近い仕様だった、って感じです。 よかったのは、 ErrorType は enum タイプセーフなエラー情報 エラー処理が強制されている(検査例外のような形) try! でエラーを無視できる あたりです。個人的には、 try, catch でなく Either 的なものを公式サ
Rails Advent Calendar 12 日目です。 特になにもしていないと、運用中の Rails アプリケーションで例外が起こっても、気づくのは困難です。 New Relic とか使うとそのあたりは解決しそうな気もしますが (あんまり使ってないので知らない)、簡単に導入できるものとして exception_notification を紹介します。 exception_notification exception_notification は Rack ミドルウェアで、捕捉されない例外が起こったときに、あらかじめ設定したメールアドレスにメールを送信します。 メール送信後は同じ例外をもう一度 raise するので、そのあとの処理に影響を及ぼすことはありません。 導入 歴史的経緯により notifi__cation__ の箇所と notifi__er__ の箇所があるので注意。 gem
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 現代のC++で例外安全問題を抜きにして、障害に強い強固なコードを書くことはほとんど不可能に近い。以上。 Hurb Sutter [1] 例外処理における目的は、例外の回復と例外の通知の大きく2つあります。残念ながら例外の回復はとても難しく、場合によってはそもそも不可能だったりします。その場合、例外が発生したことをより上位のレイヤーに通知する事で例外処理を託します。この時、例外の通知を受け取った側は何を前提に例外の回復を行えばよいでしょうか。例外の発生によってデータ整合性は崩れてしまっているかもしれません。通知を受け取った上位レイヤーはあ
例外やエラー、それにまつわる各種言語の取り組み等を共有しましょう。 11月末までに書き手が集まらなかった場合は主催者による独りAdvent Calendarと化します。 集まらなかったので残念ながら独りAdvent Calendarと化しました。 追記 独りAdvent Calendarですが、以下の理由で頓挫しました。6日目以降はお好きにご活用ください。 http://qiita.com/Kokudori/items/3a953c00012408f76ab9#%E4%BE%8B%E5%A4%96-advent-calendar-2014%E3%81%AE%E7%B6%99%E7%B6%9A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
Swift で気になった事 Swiftの仕様及び現状のSwiftコンパイラの動作について気になった事があったのでメモ。 例外処理が無い 例外が発生するような状況は、Optionalでnilを返すか、またはエラーで停止する。 割り切った仕様で、良いと思う。 Optionalを使えば、ぬるぽにもならずに大概の場合は対応出来る。 初期のJavaでのthrows節地獄でJavaが嫌いになって以来、Javaには触れてないんだけど、今のJavaの例外処理はどうなってるかな? いや、あまり興味無い。 Trailing closure が便利 元々Rubyで発明された機能(だと思う)。 使い方によってプログラムの見通しが良く簡潔に書ける場合があるので、積極的に使いたい。 yieldが無い yieldが使えれば、イテレータ、ジェネレータ、コルーチン、軽量スレッドなどがとても記述し易いので是非欲しかった。 仕
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く