Go言語のエラーハンドリングとログローテーション | RE:ENGINES
はじめに こんにちは、今回はGo言語でのエラーハンドリングとログ関連についての記事となります。 例外のないGo言語でどのようにエラーを伝搬させていくのかについて一つの方法を紹介させていただき、その後、そのエラーをファイルに出力する方法を紹介したいと思います。 なお、開発環境の構築がまだの方は、ぜひこちらで環境構築をしてからお読みいただければと思います。 エラーハンドリングについてですが、まずはGo言語でerrorとは一体何ものなのかについて触れたいと思います。その後、pkg/errorsパッケージでerrorをwrapをする方法を記載し、次の節でそれを活用した独自のerrorsパッケージを作成したいと思います。 error インターフェース Go言語では例外の概念がないため（Go2では例外が組み込まれるかもしれませんが）、ファイルの処理などで下記のようにerrorを返却するコードをよく目に
DataBindingが原因のビルドエラー時にエラーを抽出するスクリプト - visible true
AndroidでDataBinding周りミスるとめっちゃエラー出て辛いですね。辛いのでDataBindingのエラーを抽出するスクリプトを書きました。スクリプトはかなり雑なので適宜いい感じにしてください。 extract_data_binding_error.rb #! /bin/sh exec ruby -S -x "$0" "$@" #! ruby state = 0 while str = STDIN.gets break if str.chomp == "exit" case state when 0 state = 1 if str.match(/.*Found data binding errors.*/) when 1 state = 2 if str.match(/.*e: .*/) next if state == 2 print str end end gradleの
新人プログラマの時に知っておきたかった「ハマったときの考え方とフローチャート」｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
はじめに プログラムを書いたことがある人なら、誰しも「ハマる」という状況に陥ったことがあると思います。 ハマるとは、一般的には何かから抜け出せなくなってしまうことを意味しますが、システム開発の世界では、ある課題やエラーなどに対して、解決の見込みが見えないまま多くの時間をかけてしまうことを意味します。 今回は、ハマってしまったときに、いかに問題を解決し、ハマった状態から脱却するかについて書きたいと思います。 目次 問題解決における6つの基本 最初に、問題解決の基本的な考え方を書いておきます。当たり前のことばかりだと感じるかもしれませんが、この基本が完璧にできていれば、ハマることはそもそも稀だと思っています。 もし、普段の実装の中で「同じことで丸1日悩んでいるけど解決の手立てがない」「これにさえ気付いていればもっとはやくできた」「単純なミスだった」といったことに時間を溶かしているのであれば、問
「小さいエラー」をたくさん踏んだほうがいい - インターネットの備忘録
管理職の仕事って、「わたしがカバーできる範囲内でならどんどんミスっていいよ、って部下に任せて、何かあったら粛々と責任を取っていくことだよね」みたいな話をしました。 仕事の権限委譲って重要で、何かあったら責任は取るからやってみて、って思い切れない人が管理職につくと、チームが硬直してしまうし、業務もスタックしてしまう。そして、ミスでしか得られない知見もあるはずなので、必ずしもミス＝悪ではない、という前提をもって任せる。そういう腹のくくり方が管理職には必要で、その覚悟を引き受けるから権限をもらえたり、お金をたくさんもらえたりするんだよね、という感じ。 という覚悟を持って仕事を渡しているので、メンバーには「こっからここの範囲内なら、いろいろトライしてみていいよ」と言って任せられたら、じゃんじゃん挑戦してミスってみてほしいなと思っているんですが、なかなかそうもいかないようです。 たとえば、経験が浅い
SwiftはどのようにJavaの検査例外を改善したか - Qiita
僕は、 Java の検査例外のコンセプトは素晴らしいと考えていますが、世間ではあまり好かれていないようです。 C# や Scala, Kotlin などの後続言語では採用されず、僕の知る限り Java 以降、検査例外（的なもの）を採用したメジャー言語は Swift だけです。 ただし、Swift の検査例外（的なもの）はいくつかの点で Java の検査例外と異なっています。 Swift は後続だけあって何かしらの改善を試みているわけです。その取り組みがおもしろいので、 Swift の検査例外的なものが Java の検査例外と何が違い、それがどのような意味を持つのかを紹介します。 throws 節でエラーの型を指定できない Java では
Windowsで表示されるエラーコードの見方
Windowsでエラーがあるたびに表示される「エラーコード」。コードを調べると原因がわかるとされているが、インターネットでキーワード検索をしてみたところで、まともな答えが得られないことのほうが多い。よくてエラーコードの意味を理解しないで、単に対策だけが記載されている程度だ。 そこで、今回はこのエラーコードを解説することにしよう。とりあえず、マイクロソフトが出している正式なドキュメントは以下にある。 ●[MS-ERREF]: Windows Error Codes https://msdn.microsoft.com/en-us/library/cc231196.aspx 基本的には、これを読めばいいわけなのだが、量も結構あって、しかも英語である。そこで、今回は、よく見かけるエラーコードなどを例に、ごく大まかに解説することにする。 Windowsのエラーコードは、32bit値で、通常は16進
デスマってるゲーム会社を舞台にしたアニメ
NEW GAME! という、美少女しかいないゲーム会社を描く作品がある。 放映開始当初から「働くおっさんたちが過労のあまり幻視している理想の会社」という言説がありまして。 この仮説を裏打ちする根拠は作品全体を通して随所に見られるが、ここでは第七話を例に論証してみるぞい。 OPの歌詞めぐりめぐってEveryone（連帯責任） 何かが待っているのかな？（納期） 強くなれる（圧倒的成長環境） そう君は1人じゃないよ（失踪するなよ） Stand up★（朝礼） 何気ないような朝がきた（絶望） おふとんが いとしいな（出社拒否） 楽しい一日になるよ（自己暗示） 走りだそう（通勤ダッシュ） エアガンでの打ち合い純粋な殺意の現れ。 上司への？ それとも会社？ 仕事？ ……すべて。 散弾銃の薬莢楽になりたい。 デスクに飾られた大量のライフル乱射事件の伏線。 デスクに飾られた大量のおもちゃオーバーワークによ
PHPの次
ああまたか、と思った。フレームワークを使用しているのに、フォームフィールドをベタ書きして、条件分岐を駆使して、その値や、エラー文字列を表示させている。 外注が作ったプログラム。 初めはもちろん頭にきたが、なんかもう、PHPってこんなもんなのかな、と思った。 こういうコードを見たのは一回でも、一社でも、ない。 それでもこの会社たちはこれで仕事をもらい金をもらい回っている。 所詮私が関われるレベルの仕事だ。別に大した規模でもない。悪党たちや、暇人たちが、ちょっかいだすメリットなどない。 BASIC認証があってデータベースのアカウント認証があって一部の限られた人しか使わなくて…。それでも私は入力値チェックをする。入力画面と確認画面と処理画面で、する。エスケープをする。SQLはLIKE文のエスケープも、するよ？HTML出力は文字列全部にエスケープするから、名前に記号、使えるよ？ 当たり前だよね？
「ヒューマンエラー」は個人の責任ではない
人間にまつわるセキュリティを考える本連載。今回のテーマは「ヒューマンエラー」です。個人の意識だけに原因を求めてもうまくいかないヒューマンエラー対策について考えます。 連載目次 ヒューマンエラーを考える 心理学などの知見を借りながら、「人間のセキュリティ」を考える本連載。第5回では、組織の「ヒューマンエラー対策」を扱います。情報セキュリティに限らず、多くの事件・事故は、ヒューマンエラーが主要な原因となって起きています。 図表1はNRIセキュアテクノロジーズが2015年に行った調査の結果です。これを見ると、企業におけるセキュリティ事故の大部分は、「ヒューマンエラー」と「サイバー攻撃」によるものだと分かります。また、この調査の中でサイバー攻撃として分類されている幾つかの項目も、考え方によってはヒューマンエラーに起因するものと捉えることができます（標的型メール攻撃など）。 図表1 過去1年間に発生
WebAPIを勢いで作って失敗した小話と解決のポイント - アニメイトラボ開発者ブログ
この記事はanimateLAB Advent Calendar2015 7日目の記事です。 はじめまして。アニメイトラボに11月からWeb/アプリエンジニアとしてジョインしましたかんがー（@KangalMi）と申します。 新卒で入社した会社から非公開なWebAPIとiOS/Androidアプリの開発を行ってきました。 現在はアニマートのWeb側をメインに担当をしています。 今回は、僕がWebAPIを開発・運用する中で失敗したことをお伝えします。 エラーコードの上手な表現方法 自分が開発したものではエラーの表現を下のような形で常に返却していました。 "meta": { "status": 500, "message": "ユーザーの作成に失敗しました。" } 上記はmeta以下にエラー関連の情報をエンベロープで包み、statusはHTTPステータスコードに準拠したコードを、messageには
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
