Content-Length: 272793 | pFad | http://b.hatena.ne.jp/moronbee/error/

[B! error] moronbeeのブックマーク

タグ

関連タグで絞り込む (15)

タグの絞り込みを解除

errorに関するmoronbeeのブックマーク (10)

  • いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita

    はじめに [ $? -eq 0 ] や [ $? -ne 0 ] は冗長でデメリットしかありません。非常に多く見かける書き方ですが、1979 年に Bourne シェルが広く公開された時からこのようなコードは必要ありませんでした。実際に当時はこのような書き方は使われておらず、このような書き方をしなければならなかった歴史的な経緯などはありません。これはなぜか広まってしまった良くない書き方です。 優れたコードとは無駄がないシンプルなコードです。丁寧なコードとは無駄な処理を書くことではありません。[ $? -eq 0 ] や [ $? -ne 0 ] は書かないほうが、簡単で読みやすくわかりやすくなります。優れた文法を持つシェルは短いコードで正しく動作し、良い書き方は最短の時間と最小の手間で目的を達成することができます。コマンドのエラー処理を簡潔に書くことができるのが、シェル言語の優れている点の

    いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita

  • Rails: macOSをMojaveにアップグレード後`bundle install`がエラーになった場合の対応方法｜TechRacho by BPS株式会社

    2018.10.10 Rails: macOSをMojaveにアップグレード後`bundle install`がエラーになった場合の対応方法 問題 macOSをHigh Sierra（10.13）からMojave（10.14）にアップグレードした後、Railsアプリを新規作成するためにbundle installすると以下のエラーが発生しました。 なお、私のMacBook ProにはXcodeは入れておらず（サイズがでかすぎるので）、CommandLineTools（Command_Line_Tools_macOS_10.13_for_Xcode_10.dmg）をインストールしていましたが、Mojaveにアップグレードした機会にhttps://developer.apple.com/download/more/から現時点で最新のCommand_Line_Tools_macOS_10.14_

    Rails: macOSをMojaveにアップグレード後`bundle install`がエラーになった場合の対応方法｜TechRacho by BPS株式会社

  • Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita

    これは Swift Tweets の発表をまとめたものです（次回開催はこちら）。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました！Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし

    Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
    moronbee
    moronbee 2017/01/16
    "Simple domain error / Recoverable error / Universal error / Logic failure"、"『どのように対応させたいか』というところがキモ"
    リンク

  • HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様

    今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application

  • 大手Webサービスがクライアント側で発生したJavaScriptのエラーをどう収集しているのか まとめ - Qiita

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

    大手Webサービスがクライアント側で発生したJavaScriptのエラーをどう収集しているのか まとめ - Qiita

  • railsで、複数の出力先にlogを出力する · Yuichi Takada

    railsアプリケーションで、error以上のレベルのログだけ、２箇所にログを出力したいと思った。 前提 ruby 2.1.2 rails 4.1.4 方法 まず、複数の出力先にロギングするには、ActiveSupport::Logger.#broadcastというメソッドが使える。 config/application.rbのMyapp::Applicationクラス内に下記のように書いてみた。 logger = ActiveSupport::Logger.new(config.paths["log"].first) error_logger = ActiveSupport::Logger.new("log/error.log") error_logger.level = Logger::ERROR logger.extend ActiveSupport::Logger.broadcas

  • RailsでAPIをつくるときのエラー処理 - Qiita

    例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という

    RailsでAPIをつくるときのエラー処理 - Qiita

  • 米市場で原油価格が短時間に急落、問題起きた可能性

    ［ニューヨーク／ワシントン　１７日　ロイター］　１７日の米市場で、原油価格がわずか４分間に４ドル前後急落する場面があり、米商品先物取引委員会（ＣＦＴＣ）が調査に乗り出した。トレーダーは、注文の入力ミスや、コンピューターによる超高速売買（ＨＦＴ）に問題が生じた可能性があるとみている。 この日は市場に影響を与える大きなニュースがなかったにもかかわらず、インターコンチネンタル取引所（ＩＣＥ）では１バレル１１６．６７ドルで取引が始まった北海ブレント原油１１月限が一時１１１．５０ドルまで急落。米東部時間午後１時５２分（日本時間１８日午前２時５２分）から１時５５分までの３分間だけで３．６０ドル下落した。その後は急速に値を戻し、２．８７ドル安の１１３．７９ドルで取引を終えた。 ニューヨーク・マーカンタイル取引所の米原油先物も、短時間に大量の商いを伴って急落。急落前には期近物である１０月限の出来高が１５１

    米市場で原油価格が短時間に急落、問題起きた可能性
    moronbee
    moronbee 2012/09/18
    人が制御できないものを生み出した事実の表出。度々あるとは思うけど、人命に関わる惨事にはならないよう制御してほしい(安全装置)と思う。
    リンク

  • 京の路: RailsのProduction環境でErrorを管理者にメールで自動通知する方法（ErrorMail on Rails）

    アプリケーションを本番環境に移行すると、ブラウザではエラーの詳細が表示されませんし、ユーザはエラーの発生を教えてくれる訳ではありません。そこでエラーが発生したときには、エラーメッセージの内容を、管理者へ自動的にメールしてくれると助かります。 今回はRailsでエラーメッセージを自動送信する方法についてです。内容はRails本に書いてある通りだけど。 まず、Railsでエラーが発生した場合、必ず呼ばれるメソッドが、 rescue_action_in_public(exception) です。こいつをオーバーライドすることで、エラーメッセージを送信できるようにしてやります。 まず、ApplicationControllerに以下のメソッドを追加します。（app/controllers/application_controller.rb） def rescue_action_in_public(

  • Railsでエラーページを表示する. - 考え得る最高を常に行う

    いつもpublic/404.htmlとか編集してる程度だったので、Railsの仕組みを使ったエラーページを作ろうかと色々試行錯誤してみた. 因にエラーページは通常はProductionモードでHTTPアクセスをローカルホスト( localhost / 127.0.0.1 )以外でアクセスしたときに確認できます. エラーページの実装方法 方法はググってみると、ざっと3種類あった. public/404.htmlを書き換える ApplicationController内でrescue_fromを追記 ApplicationController内でrescue_action_in_publicメソッドをオーバライド 色々やるなら、最後のrescue_action_in_publicオーバライドする方法が一番よさそう. ただ欲を言うとRails自身もProductionモードのときちゃんと、404

    Railsでエラーページを表示する. - 考え得る最高を常に行う
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2025 Hatena. All Rights Reserved.








 ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://b.hatena.ne.jp/moronbee/error/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy