タグ

panicに関するhiroyukimのブックマーク (4)

  • lestrrat-go/fluent-clientの紹介

    あるときGo言語のアプリで使うfluentdクライアントが必要になりました。色々見た後、「あ、俺自前のクライアントを書こう!」と思い立ち、イチから書いてみる事にしてみました。 (エントリはGo2 Advent Calendarの12/1のエントリです) 結果的に出来たライブラリは良い感じで並行処理がされている気がするので、この記事はその並行処理について解説してみます。 モチベーションまず、そもそもなんで公式のライブラリ使わないの?というところから。

    lestrrat-go/fluent-clientの紹介
  • Go言語のCLIツールのpanicをラップしてクラッシュレポートをつくる

    mitchellh/panicwrap Go言語でpanicが発生したらどうしようもない.普通はちゃんとテストをしてそもそもpanicが発生しないようにする(もしくはトップレベルでrecoverする).しかし,クロスコンパイルして様々な環境に配布することを,もしくはユーザが作者が思ってもいない使いかたをすることを考慮すると,すべてを作者の想像力の範疇のテストでカバーし,panicをゼロにできるとは限らない. panicが発生した場合,ユーザからすると何が起こったか分からない(Go言語を使ったことがあるユーザなら「あの表示」を見て,panicが起こったことがわかるかもしれない).適切なエラーメッセージを表示できると良い.開発者からすると,そのpanicの詳しい発生状況を基に修正を行い,新たなテストケースを追加して二度とそのバグが発生しないようにしておきたい. mitchellh/panicw

  • panicはともかくrecoverに使いどころはほとんどない - Qiita

    Goを書いていてrecoverを使うことはまずほとんどない。頻繁にrecoverを書いているとしたらなにかが間違っているのでプログラミングスタイルを見直すこと。 Goでのエラーハンドリング Effective Goなどで説明されているように、Goではエラーは関数の返り値として返される。たとえばio.ReaderのRead関数は、読み込んだバイト数と、(nilかもしれない)エラーの2つの値を返す。Goでは基的に、エラーは常にこういう通常の値としてハンドルするべきで、エラーの時のための特別な制御構造(try 〜 catch)のようなものを使うのは、利点より害のほうが多いという考え方をとっている。 (同じような考えで例外を使用禁止にしている大規模C++プログラムはいくつもある。たとえばChromiumなどはそうだ。LLVM/Clangもパフォーマンス上の問題で例外を使っていない。C++コンパイ

    panicはともかくrecoverに使いどころはほとんどない - Qiita
  • RHEL(CentOS)6系でトラフィックをたくさん捌くサーバが死ぬ問題は6.5のkernel-2.6.32-431.el6以降で多分直る - このブログはURLが変更になりました

    タイトルで言いたいことはすべて言った。 経緯 うちの場合はLVS+keepalivedなロードバランサなんだけど、ちょくちょくkernel panicになる問題が発生してた。 そこでcrashコマンドで解析してみた。crashコマンドの使い方はこちらが参考になる。Linux crash dump 読み方入門 # crash /boot/System.map-2.6.32-279.14.1.el6.x86_64 /usr/lib/debug/lib/modules/2.6.32-279.14.1.el6.x86_64/vmlinux /var/crash/127.0.0.1-2013-09-27-16\:21\:01/vmcore (snip) SYSTEM MAP: /boot/System.map-2.6.32-279.14.1.el6.x86_64 DEBUG KERNEL: /usr

    RHEL(CentOS)6系でトラフィックをたくさん捌くサーバが死ぬ問題は6.5のkernel-2.6.32-431.el6以降で多分直る - このブログはURLが変更になりました
  • 1