平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
どうも思った通りにrescue_fromが例外を捕まえないと思ったら、下記だった。 They are searched from right to left, from bottom to top, and up the hierarchy. 右から左、下から上へ、そして継承を遡って検索される。 ずっとこの辺りのコードを弄っていなかったのだが、なぜ今まで想定通りに動いていたのだろうか…謎だ。 class ApplicationController < ActionController::Base # ... # ハンドルしきれなかったエラーは500エラー扱い # 評価は右から左、下から上へなされるのでこの場所で良い。 # @see http://api.rubyonrails.org/classes/ActiveSupport/Rescuable/ClassMethods.html res
例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という
Ruby 2.1.0-preview2 リリース では 2013-11-10 の大きめの変更 が気になっていて、 ここでは Exception#cause というメソッドを紹介します。 "literal"f のように書く freeze された文字列リテラル機能が 2.1.0-preview1 には入っていたのですが、それが削除されて "literal".freeze がコンパイル時に特別扱いされるようになった、 というのも気になっています。 この投稿は Ruby Advent Calendar 2013 の3日目の記事です。 Exception#cause の例 Ruby 2.0.0 までは rescue や ensure の中で別の例外が発生すると、 別途保存しておかない限り、 以前に発生した例外がわからなくなってしまっていましたが、 Ruby 2.1.0(-preview2) からは別
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く