あずにゃんラーメン
Goでdefer f.Close()するとUnhandled error警告されるのってどう回避すればいいの
Closerの返すerrorを無視するヘルパ書けばいいのかな（標準ライブラリにありそう）
func MustClose(c io.Closer) {
if err := c.Close(); err != nil {
panic(err)
}
}
を書きました
なんか出力するファイルハンドルをCloseするときはFlushが起きるからエラーハンドリングしろというのは分かるが、読み込みしかしないやつがエラー投げてきたときはそもそも何をすればいいのか謎
Writeのために開いたファイルがCloseで失敗したらロールバックしたくない？
謎のカーネルモジュールにプロセスの外部から干渉されてファイルデスクリプタを破壊されるとclose失敗しそう（ほんまか？）
TCPのソケットが裏にあるタイプのReaderはFIN未達でエラー吐いたりするのかな
たしか fflush() が失敗した時点で、フラッシュしようとしたデータは破棄されている可能性があって、再度フラッシュしようとしても意図したとおりにならない可能性あるんだっけ？ (うろおぼえ)
fflushがコケたらデータが失われてる可能性がある、それはそうという感じ
read-only で開いたファイルが close に失敗するの、ジャストタイミングでシグナルが飛び込んできた場合などがある
このアカウントは、notestockで公開設定になっていません。
確かにdefer使わなければいい気持ちになってきたが、一方Goはエラー時にearly returnするよう言語が設計されており……（リソース構文欲しい）
まあ結局Goはsuper better Cだからあんまり賢いことを期待してはいけないという話なのかな……
ていうかひかりのかべでははかいこうせん軽減できないのでは？
このアカウントは、notestockで公開設定になっていません。
ポケスペではひかりのかべで物理防いでた気もするし、まあ壁なんだからだいたいのものは常識的に考えて防げるでしょ
@brsywe 日本語ならこないだDuolingoでマスターしたよ