List of Defer [text.Baldanders.info]

Gzip 操作について覚え書き

2017-09-19T08:31:49+00:00

gzip のやり方 - Qiita

この記事を見て「んん？」となったので，覚え書きとして gzip パッケージについて紹介する。

リンク先の記事で挙げられているコードは以下の通り。

func makeGzip(body string) []byte {
    var b bytes.Buffer
    gw := gzip.NewWriter(&b)
    _, err := gw.Write([]byte(body)); if err != nil {
        ...
    }
    gw.Flush()
    gw.Close()
    return b.Bytes()
}

ここで gw.Close() 関数を defer 指定すると返ってくるバイト列が不完全なデータになってしまう，という話。これは，リンク先の記事で指摘されている通り， gzip.Writer.Close() 関数で gzip のフッタデータをフラッシュしているからである。

Close closes the Writer by flushing any unwritten data to the underlying io.Writer and writing the GZIP footer. It does not close the underlying io.Writer.

via gzip - The Go Programming Language

つまり defer で指定した関数は return 後に駆動するため b.Bytes() 関数を呼び出した時点ではまだ不完全なデータということになる¹。

ここでちょっと考える。

関数の再利用性を考えるのなら，関数内でバッファを生成してバッファ処理の結果を返すのはあまり筋がよろしくない。また圧縮データを書き込む先はメモリバッファじゃなくてファイルかもしれない。

ゆえに関数をこう書き換える。

func makeGzip(dst io.Writer, content []byte) error {
    zw, err := gzip.NewWriterLevel(dst, gzip.BestCompression)
    if err != nil {
        return err
    }
    defer zw.Close()

    if _, err := zw.Write(content); err != nil {
        return err
    }
    return nil
}

つまり圧縮データの書き込み先である Writer を引数で指定するのである。これなら生成した gzip.Writer.Close() 関数を問題なく defer で指定できる。

これを踏まえて完全なコードは以下のようになる。

package main

import (
    "compress/gzip"
    "fmt"
    "io"
    "os"
)

func makeGzip(dst io.Writer, content []byte) error {
    zw, err := gzip.NewWriterLevel(dst, gzip.BestCompression)
    if err != nil {
        return err
    }
    defer zw.Close()

    if _, err := zw.Write(content); err != nil {
        return err
    }
    return nil
}

func main() {
    content := []byte("Hello world\n")

    file, err := os.Create("test.txt.gz")
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
    defer file.Close()

    if err := makeGzip(file, content); err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
}

このコードでは圧縮データの書き込む先をファイルにしている。もちろん書き込み先を bytes.Buffer に置き換えることもできる。このようにインスタンスの生存期間を意識することで Go 言語の得意なパターンに嵌めることが容易になる。

ついでに対となる読み込み処理のコードも示しておこう。ここでは復元したデータを標準出力に直接出力している。

package main

import (
    "compress/gzip"
    "fmt"
    "io"
    "os"
)

func readGzip(dst io.Writer, src io.Reader) error {
    zr, err := gzip.NewReader(src)
    if err != nil {
        return err
    }
    defer zr.Close()

    io.Copy(dst, zr)

    return nil
}

func main() {
    file, err := os.Open("test.txt.gz")
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
    defer file.Close()

    if err := readGzip(os.Stdout, file); err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
}

ところで，ファイル操作では生のデータを直接 gzip 圧縮するシチュエーションは少なく，大抵は tar と組み合わせることになる。そこで tar と組み合わせ，指定フォルダ直下の複数ファイルを gzip 圧縮するコードも以下に示しておく。

package main

import (
    "archive/tar"
    "compress/gzip"
    "fmt"
    "io"
    "io/ioutil"
    "os"
    "path/filepath"
)

func makeTarGzip(dst io.Writer, rt string) error {
    zw, err := gzip.NewWriterLevel(dst, gzip.BestCompression)
    if err != nil {
        return err
    }
    defer zw.Close()

    tw := tar.NewWriter(zw)
    defer tw.Close()

    filepath.Walk(rt, func(path string, info os.FileInfo, err error) error {
        if info.IsDir() {
            return nil
        }
        fmt.Println(path)

        hd, e := tar.FileInfoHeader(info, "")
        if e != nil {
            return e
        }
        content, e := ioutil.ReadFile(path)
        if e != nil {
            return e
        }

        if e := tw.WriteHeader(hd); e != nil {
            return e
        }
        if _, e := tw.Write(content); e != nil {
            return e
        }
        return nil
    })
    if err != nil {
        return err
    }

    return nil
}

func main() {
    file, err := os.Create("test.tar.gz")
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
    defer file.Close()

    if err := makeTarGzip(file, "./"); err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
}

【追記】別解あります

実は最初の makeGzip() には別解がある。要するに gzip 処理部分を関数スコープで囲ってしまえばいいのだ。実際にはこんな感じ。

func makeGzip(body []byte) ([]byte, error) {
    var b bytes.Buffer
    err := func() error {
        gw := gzip.NewWriter(&b)
        defer gw.Close()

        if _, err := gw.Write(body); err != nil {
            return err
        }
        return nil
    }()
    return b.Bytes(), err
}

完全なコードはこんな感じになる。

package main

import (
    "bytes"
    "compress/gzip"
    "fmt"
    "os"
)

func makeGzip(body []byte) ([]byte, error) {
    var b bytes.Buffer
    err := func() error {
        gw := gzip.NewWriter(&b)
        defer gw.Close()

        if _, err := gw.Write(body); err != nil {
            return err
        }
        return nil
    }()
    return b.Bytes(), err
}

func main() {
    content := []byte("Hello world\n")

    file, err := os.Create("test.txt.gz")
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
    defer file.Close()

    z, err := makeGzip(content)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }

    if _, err := file.Write(z); err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
}

このように（defer を含む）一連の処理を関数スコープで囲うやり方は，条件分岐や繰り返し処理の中で役に立つこともあるだろう。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

この挙動から分かるとおり， bytes.Buffer.Bytes() 関数は，バッファの内容をそのまま返しているのではなく，内容のコピーを返している。 ↩︎

関数とポインタ

2016-03-29T13:16:41+00:00

いまさらな内容なのだが覚え書きとして記しておく。

Go 言語における Calling Sequence

まずは簡単な足し算の関数を定義してみる。

func add(x int, y int) int {
    return x + y
}

add に続く括弧内が引数を定義していて，括弧の後ろの int は返り値の型¹ を示している。 add() 関数を呼び出すには以下のように記述する。

package main

import "fmt"

func add(x int, y int) int {
    return x + y
}

func main() {
    ans := add(42, 13)
    fmt.Println(ans)
}

x と y は同じ int 型なので以下のように記述することもできる。

func add(x, y int) int {
    return x + y
}

返り値を組（tuple）で定義することもできる。

func split(sum int) (int, int) {
    x = sum * 4 / 9
    y = sum - x
    return x, y
}

また返り値には，以下に示すように，あらかじめ名前をつけることもできる。

func add(x, y int) (ans int) {
    ans = x + y
    return
}

最後の return がないとコンパイル・エラーになるので注意。この書き方は defer 構文と組み合わせるときに威力を発揮する。

package main

import "fmt"

func main() {
    err := r()
    if err != nil {
        fmt.Println(err)
    } else {
        fmt.Println("Normal End.")
    }
}

func r() (err error) {
    defer func() {
        if rec := recover(); rec != nil {
            err = fmt.Errorf("Recovered from: %v", rec)
        }
    }()

    f()
    err = nil
    return
}

func f() {
    panic("Panic!")
}

このコード² では r() 関数内で panic を捕まえ，返り値の err に値をセットしなおしている。

Go 言語の引数は「値渡し」

Go 言語の引数は基本的に「値渡し（call by value）」である。たとえば先程の足し算を

func add(x, y int) int {
    x += y
    return x
}

と定義した場合でも

package main

import "fmt"

func add(x, y int) int {
    x += y
    return x
}

func main() {
    x := 42
    y := 13
    ans := add(x, y)
    fmt.Printf("%d + %d = %d\n", x, y, ans) //output: 42 + 13 = 55
}

呼び出し元で add() 関数の引数に渡した instance は関数実行後も変化しない。このため引数の値渡しは thread safe なコードに向いている。ただし関数呼び出し時に instance の値が常にコピーされるため³，サイズの大きな instance の場合は呼び出し時のコストが高くなる。引数の値渡しが有利な例としては value object を構成する場合などが考えられる。

Instance の値ではなく実体を渡したいときがある。この場合はポインタを使う。つまり instance へのポインタ値を渡すのである。

package main

import "fmt"

func add(x, y *int) int {
    *x += *y
    return *x
}

func main() {
    x := 42
    y := 13
    ans := add(&x, &y)
    fmt.Printf("%d + %d = %d\n", x, y, ans) //output: 55 + 13 = 55
}

このコードでは add() 関数実行後の x の値が変更されている。このように instance へのポインタ値を引数として渡すやり方をこの記事では，通常の「値渡し」とは区別して，「ポインタ渡し」と呼ぶことにする⁴。

内部状態を持つ instance を引数に指定する場合はポインタ渡しにする必要がある。しかし引数をポインタ渡しにすると関数実行が thread safe でなくなる可能性がある。また引数の値が nil の場合も考慮する必要がある。

ちなみに Go 言語では通常の方法ではポインタ演算ができない。たとえば，ついうっかり

func add(x, y *int) int {
    x += y
    return *x
}

とか書いてしまっても

invalid operation: x += y (operator + not defined on pointer)

とコンパイル・エラーになる。したがって通常は「Go 言語のポインタは nullable 参照⁵ と同じ」と考えてよい。

なお，ポインタ演算が必要な場合は unsafe パッケージを使う。

Slice, Map, Channel は参照渡しのように振る舞う

slice, map, channel は組み込み型だが内部状態を持つ⁶。これらの型の instance を引数に渡す場合は参照渡しのように振る舞う⁷。

package main

import "fmt"

func setItem(ary map[int]int, index, item int) {
    ary[index] = item
}

func main() {
    ary := map[int]int{0: 0}
    fmt.Println(ary) //output: map[0:0]
    setItem(ary, 0, 1)
    fmt.Println(ary) //output: map[0:1]
    setItem(ary, 10, 10)
    fmt.Println(ary) //output: map[0:1 10:10]
}

ただし固定の配列や string 型⁸ の instance は「値」として振る舞うため⁹，引数に指定した場合も値渡しのように振る舞う。 slice とは挙動が異なるためテキトーなコードを書いていると混乱しやすい。

package main

import "fmt"

func setItem(ary [4]int, index, item int) {
    ary[index] = item
}

func main() {
    ary := [4]int{0, 1, 2, 3}
    fmt.Println(ary) //output: [0 1 2 3]
    setItem(ary, 1, 10)
    fmt.Println(ary) //output: [0 1 2 3]
    ary[2] = 200
    fmt.Println(ary) //output: [0 1 200 3]
}

固定配列や string 型をポインタ渡しすることはできる。もっとも string 型の instance は「不変（immutable）」なのでポインタ渡しが必要な局面はほとんど無いと思うが¹⁰。

固定配列をポインタ渡しする例は以下の通り。

package main

import "fmt"

func setItem(ary *[4]int, index, item int) {
    (*ary)[index] = item
}

func main() {
    ary := [4]int{0, 1, 2, 3}
    fmt.Println(ary) //output: [0 1 2 3]
    setItem(&ary, 1, 10)
    fmt.Println(ary) //output: [0 10 2 3]
}

固定配列は不変ではないが，配列を操作するのであれば固定配列ではなく slice のほうが扱いやすい。たとえば上のコードでは slc := ary[:] といった感じにキャストするか最初から ary := []int{0, 1, 2, 3} と初期化すれば slice として扱える。

Method Receiver

ある型に関数を関連付ける場合は method receiver を使う。

type Vertex struct {
    X int
    Y int
}

func (v Vertex) Add(dv Vertex) Vertex {
    v.X += dv.X
    v.Y += dv.Y
    return v
}

(v Vertex) の部分が method receiver である。 Add() 関数を呼び出すには以下のように記述する。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v Vertex) Add(dv Vertex) Vertex {
    v.X += dv.X
    v.Y += dv.Y
    return v
}

func main() {
    v := Vertex{X: 1, Y: 2}
    vv := v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v)  //output: X = 1, Y = 2
    fmt.Println(vv) //output: X = 4, Y = 6
}

関数の calling sequence としては v.Add(dv) と Vertex.Add(v, dv) は等価である。つまり v は Add() 関数の0番目の引数として振る舞い，値渡しでセットされる。

Method receiver の型をポインタ型にすればポインタ渡しにできる。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v * Vertex) Add(dv Vertex) {
    if v == nil {
        return
    }
    v.X += dv.X
    v.Y += dv.Y
}

func main() {
    v := &Vertex{X: 1, Y: 2}
    v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v) //output: X = 4, Y = 6
}

この場合も calling sequence としては v.Add(dv) と (*Vertex).Add(v, dv) は等価である。

Method Receiver の暗黙的変換

Method receiver を値にした場合，呼び出し元の instance がポインタ型であっても暗黙的にコピーが発生し値渡しに変換される。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v Vertex) Add(dv Vertex) Vertex {
    v.X += dv.X
    v.Y += dv.Y
    return v
}

func main() {
    v := &Vertex{X: 1, Y: 2} //pointer
    vv := v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v)  //output: X = 1, Y = 2
    fmt.Println(vv) //output: X = 4, Y = 6
}

Method receiver をポインタにした場合も，やはり暗黙的にポインタ渡しに変換される。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v *Vertex) Add(dv Vertex) {
    if v == nil {
        return
    }
    v.X += dv.X
    v.Y += dv.Y
}

func main() {
    v := Vertex{X: 1, Y: 2} //not pointer
    v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v) //output: X = 4, Y = 6
}

Method Receiver の値が nil の場合

Method receiver の値が nil の場合はどうなるか。まずは値渡しの場合。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v Vertex) Add(dv Vertex) Vertex {
    v.X += dv.X
    v.Y += dv.Y
    return v
}

func main() {
    v := (*Vertex)(nil) //nil
    vv := v.Add(Vertex{X: 3, Y: 4}) //panic!
    fmt.Println(v)
    fmt.Println(vv)
}

この場合は Add() 関数呼び出し時に panic になる。

panic: runtime error: invalid memory address or nil pointer dereference

まぁこれは分かりやすいよね。ではポインタ渡しの場合はどうなるか。

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func (v *Vertex) Add(dv Vertex) {
    if v == nil {
        return
    }
    v.X += dv.X
    v.Y += dv.Y
}

func main() {
    v := (*Vertex)(nil) //nil
    v.Add(Vertex{X: 3, Y: 4})
    fmt.Println(v) //output: <nil>
}

実は Add() 関数呼び出し時点では panic にはならない。上のコードでは v に nil が渡される。したがって Add() 関数内の条件文を削除すると

func (v *Vertex) Add(dv Vertex) {
    v.X += dv.X //panic!
    v.Y += dv.Y
}

v 内の要素を参照しようとしたところで panic になる。 Method receiver をポインタ渡しにする場合は nil 値に注意する必要がある。

for-range 構文も値渡し

余談だが for-range 構文も値渡し（つまりコピーが発生する）ので注意が必要である。たとえば以下のコードで

package main

import "fmt"

func main() {
    ary := []int{0, 1, 2, 3}
    fmt.Println(ary) //output: [0 1 2 3]
    for _, item := range ary {
        item += 10
    }
    fmt.Println(ary) //output: [0 1 2 3]
}

for-range 構文内の item は ary 内の要素を指すのではなく要素のコピーである。したがって item を操作しても ary には影響しない。 ary 内の要素を操作するのであれば素朴に

package main

import "fmt"

func main() {
    ary := []int{0, 1, 2, 3}
    fmt.Println(ary) //output: [0 1 2 3]
    for i := 0; i < len(ary); i++ {
        ary[i] += 10
    }
    fmt.Println(ary) //output: [10 11 12 13]
}

とするしかない。

ブックマーク

型については「Go 言語における「オブジェクト」」を参照のこと。 ↩︎
このコードについては「エラー・ハンドリングについて」で解説している。ちなみに panic を潰して error を返すのはエラー・ハンドリングとしては推奨できない。 ↩︎
値がどこにコピーされるかは型によって異なる。 string 以外の基本型は値がスタックに積まれる。 string および基本型以外はヒープ領域に値がコピーされその参照（＝ポインタ）がスタックに積まれる。 ↩︎
以前は，「値渡し」に対置する言葉として「参照渡し（call by reference）」と書いていたが，最近は「もう参照渡しとは言わせない」とか言う原理主義者がいるそうで，言いがかりに巻き込まれないよう「ポインタ渡し」と言い回しを変えることにした。やれやれ。 ↩︎
nullable 参照は「null を許容する参照」くらいの意味。 Go 言語なら nil 値。 Go 言語は「null 安全（null safty）」ではないので null 参照（＝無効な参照）の始末について instance を参照する側が責務を負うことになる。（参考：「null 安全」について） ↩︎
slice, map, channel は内部状態を持つため new() 関数ではなく make() 関数を使う。 ↩︎
詳しくは「配列と Slice」および「Map の話」を参照のこと。 ↩︎
string 型の実体は []byte 型である。 ↩︎
固定の配列や string 型の instance は nil 値を持たない「non-null 参照」と言える。ちなみに string 型のゼロ値は空文字列である。 ↩︎
このような需要としては文字列操作で「NULL 状態」が必要な場合であろう。たとえば DBMS にアクセスする場合は NULL 状態を扱う必要がある。なお Go 言語のコア・パッケージには database/sql があり NullString を使うことにより NULL 状態を扱える。このように NULL 状態を扱う必要がある場合は，直にポインタ操作するのではなく，何らかの value object を用意してカプセル化するほうが安全である。 ↩︎

エラー・ハンドリングについて（追記あり）

2015-09-29T15:27:48+00:00

C++ や Java のような言語圏から来た（私のような）人間にとって Go 言語の「オブジェクト指向」はかなり異質なのだが，慣れてみると逆にとても合理的に見えてくる。なんで C++ や Java はこのようなアプローチをとらなかったのか不思議なほどである。

この最たるものがエラー・ハンドリングだ。

Go 言語には「例外」がない

「例外（exception）」は本来の処理の流れをぶった切って「大域脱出」するための仕組みである。でも考えてみれば例外というのはかなり微妙な言語仕様だ。

例外が抱える問題というのは本質的に goto 文の問題と同じ¹。オブジェクトの状態ごと脱出するため，（脱出前ではなく）脱出後にオブジェクトの後始末を記述せざるを得ないし，記述するためには脱出前の状態（の可能性）を「知識」として知っていなければならない²。もし後始末をきちんとしないと，それがバグやリークやその他の脆弱性のもとになる。

Go 言語はそんな面倒くさいことは考えない。どうするかというと，普通に返り値に error を返す。

file, err := os.Open(filename)

error は無視することもできる³。

file, _ := os.Open(filename)

検出した error はその場で処理して抜けてしまえばよい。

file, err := os.Open(filename)
if err != nil {
    fmt.Fprintln(os.Stderr, err)
    return false
}

開始処理と終了（後始末）処理が対になっている場合（Open/Close とは限らない）は Defer 構文で終了処理を保証する⁴。

file, err := os.Open(filename)
if err != nil {
    fmt.Fprintln(os.Stderr, err)
    return false
}
defer file.Close()

これが Go 言語の基本的な書き方。特徴的なのは，ある処理に纏わる処理をセットで記述できる点である。 try と catch と finally の間で目線を行ったり来たりさせなくても，「そこ」だけを見れば把握できる。ある意味でとても文芸的なコード⁵ であると言える⁶。

error

ここで error について改めて説明しておく。 error は以下の形式で表現できる interface 型のひとつである⁷。

// The error built-in interface type is the conventional interface for
// representing an error condition, with the nil value representing no error.
type error interface {
    Error() string
}

つまり Error() 関数を持つオブジェクトなら error として使える。これのいちばん簡単な実装が errors パッケージである。 errors パッケージの中身は以下のようになっている。

package errors

// New returns an error that formats as the given text.
func New(text string) error {
    return &errorString{text}
}

// errorString is a trivial implementation of error.
type errorString struct {
    s string
}

func (e *errorString) Error() string {
    return e.s
}

これは実体として string 型の property がひとつだけあって Error() 関数で property をそのまま返すというものだ。 Go 言語の標準パッケージの多くはこの errors パッケージを使って error を定義している。たとえば os パッケージの最下位の error は以下のように定義されている。

package os

import (
    "errors"
)

// Portable analogs of some common system call errors.
var (
    ErrInvalid    = errors.New("invalid argument")
    ErrPermission = errors.New("permission denied")
    ErrExist      = errors.New("file already exists")
    ErrNotExist   = errors.New("file does not exist")
)

もう少し複雑な error では，以下のように詳細情報を持つものもある。

// PathError records an error and the operation and file path that caused it.
type PathError struct {
    Op   string
    Path string
    Err  error
}

func (e *PathError) Error() string { return e.Op + " " + e.Path + ": " + e.Err.Error() }

3つのエラー・ハンドリング

error を判別する方法としては以下の3つがある。

error インスタンスを比較する
error の型を判別する
Error() 関数で出力される文字列を解釈する

インスタンスを比較する

あらかじめ定義済みの error インスタンスがあれば，インスタンスの比較で判別できる。

if err != nil {
    switch err {
    case os.ErrInvalid:
        fmt.Fprintln(os.Stderr, "引数が不正")
    case os.ErrPermission:
        fmt.Fprintln(os.Stderr, "アクセスは許可できない")
    case os.ErrExist:
        fmt.Fprintln(os.Stderr, "そのファイルは既にある")
    case os.ErrNotExist:
        fmt.Fprintln(os.Stderr, "ファイルが存在しない")
    default:
        fmt.Fprintln(os.Stderr, err)
    }
    return
}

単純にエラーの種類が分かればいいのであれば，この方法が最もシンプル。

型を判別する

error は interface 型なので Conversion 構文で判別できる。

if err != nil {
    switch e := err.(type) {
    case *os.PathError:
        if errno, ok := e.Err.(syscall.Errno); ok {
            switch errno {
            case syscall.ENOENT:
                fmt.Fprintln(os.Stderr, "ファイルが存在しない")
            case syscall.ENOTDIR:
                fmt.Fprintln(os.Stderr, "ディレクトリが存在しない")
            default:
                fmt.Fprintln(os.Stderr, "Errno =", errno)
            }
        } else {
            fmt.Fprintln(os.Stderr, "その他の PathError")
        }
    default:
        fmt.Fprintln(os.Stderr, "その他のエラー")
    }
    return
}

error に状態（status）を持たせる必要がある場合は，この方法を使うべき。

文字列を比較する

上述の方法で判別できない場合は Error() 関数で出力される文字列を解釈して処理するしかない。バッドノウハウ。

エラー・ハンドリングの設計

エラー・ハンドリングの方針としては，以下の2つのうちのどちらかだろう。

error を下位ロジックから上位ロジックまで持ち回し，最上位ロジックで最終的な判定と処理を行う
下位ロジックの error をカプセル化した新たなインスタンスを生成し上位ロジックに渡す。上位ロジックは直近のロジックの error のみが見える

最初のやり方は一見よさげだが，この方針では上位ロジックが下位ロジックの全ての error を把握している必要があり現実的でない。またオブジェクト指向設計では “Don’t talk to strangers” の原則があり，いわゆる「友達の友達」のことは知らないふりをするのがよい設計と言われている。

こう考えると文字列での比較は最も下策であると言える。また，型を判別する場合でも，下位レイヤの状態を生のまま見せるのではなく，必要な情報のみを返す関数を実装するほうが上策と言えるだろう。

もうひとつ考慮すべき点としてエラー・メッセージの設計が挙げられるだろう。 error に対するメッセージをどのように設計するかは（大規模アプリケーションでは特に）重要である。

（「Error の構造化」および「エラー・ハンドリング再考」へ続く）

【追記】 Panic と Recover

たとえばゼロ除算を行った場合や配列などで領域外を参照・設定しようとした場合，あるいは allocation に失敗した場合など，致命的なエラーが発生する場合がある。

package main

import "fmt"

func main() {
    f()
}

func f() {
    numbers := []int{0, 1, 2}

    fmt.Println(numbers[3])
}

これを実行すると

C:\workspace\go-practice\src\panic01>go run panic01.go
panic: runtime error: index out of range

goroutine 1 [running]:
main.f()
        C:/workspace/go-practice/src/panic01/panic01.go:12 +0x14a
main.main()
        C:/workspace/go-practice/src/panic01/panic01.go:6 +0x1b
exit status 2

となり，大域脱出させてアプリケーションを強制終了させているのが分かる。この仕組みを Panic と呼ぶ。

Panic は意図的に発生させることもできる。

package main

func main() {
    f()
}

func f() {
    panic("Panic!")
}

これを実行すると

C:\workspace\go-practice\src\panic02>go run panic02.go
panic: Panic!

goroutine 1 [running]:
main.f()
        C:/workspace/go-practice/src/panic02/panic02.go:8 +0x6c
main.main()
        C:/workspace/go-practice/src/panic02/panic02.go:4 +0x1b
exit status 2

となる。

一方で， Panic を Recover することもできる⁸。

package main

import "fmt"

func main() {
    err := r()
    if err != nil {
        fmt.Println(err)
    } else {
        fmt.Println("Normal End.")
    }
}

func r() (err error) {
    defer func() {
        if rec := recover(); rec != nil {
            err = fmt.Errorf("Recovered from: %v", rec)
        }
    }()

    f()
    err = nil
    return
}

func f() {
    panic("Panic!")
}

これを実行すると

C:\workspace\go-practice\src\panic03>go run panic03.go
Recovered from: Panic!

となる。 Panic を Recover で捕まえて通常の error として返しているのがお分かりだろうか。

一般的に Panic はアプリケーション内で続行不可能な致命的エラーが発生した場合に投げられる。例えばゼロ除算や領域外アクセスのようなエラーは Panic が発生する前に回避するコードにすべきだ。 Allocation エラーのような回避不能かつアプリケーション続行不可能なエラーの場合は Panic が投げられるのもやむを得ないが， Recover することにほとんど意味はない。

例外的な使い方として bytes.Buffer では，メモリ確保で panic が発生した際に Recover で捕まえ， error インスタンスを入れ替えて Panic を投げ直している。このような用途で Recover を使うことはあり得る。

// makeSlice allocates a slice of size n. If the allocation fails, it panics
// with ErrTooLarge.
func makeSlice(n int) []byte {
    // If the make fails, give a known error.
    defer func() {
        if recover() != nil {
            panic(ErrTooLarge)
        }
    }()
    return make([]byte, n)
}

また再帰処理中に続行不能なエラーが発生した場合に Panic を投げてトップレベルの関数に一気に復帰するような使い方をすることもある。この場合，トップレベルの関数は（続行不可能なら）改めて Panic を投げるか（処理続行できる根拠があるのなら）通常の error を返すことになる⁹。

いずれにしろ，いわゆる「例外処理」的なハンドリングを Panic/Recover で行うべきではない。

【追記】 error の nil が nil にならない場合

Why Go is a poorly designed language — Medium （日本語訳）

このコードの実行結果は “Hello, Mr. Pike!” を出力する。このコードのポイントは Generate() 関数が error ではなく *MagicError 型を返している点にある。

実は error を含む interface 型のインスタンスは値（への参照）と型情報をセットで保持っているため，上述のような形で nil を返しても受け取った側は「nil 状態を持つなにか」という評価になり，ただの <nil> にはならないのだ。

research!rsc: Go Data Structures: Interfaces

たとえば上のコードを以下のように書き換えると分かりやすいかもしれない。

package main

import "fmt"

type MagicError struct{}

func (m *MagicError) Error() string {
    return fmt.Sprintf("%#v", m)
}

func Generate() *MagicError {
    return nil
}

func Test() error {
    return Generate()
}

func main() {
    if err := Test(); err != nil {
        fmt.Println(err)
    }
}

このコードを実行すると “(*main.MagicError)(nil)” と出力する。 Generate() 関数が返す nil がどのように機能しているか分かると思う。「Go 言語における「オブジェクト」」で解説するが， Go 言語の型（type）は C++ や Java で言うところの class のように機能するため，このような動きになると思われる¹⁰。

エラーハンドリングを行う際は結構ここがハマりどころになる。ご注意を。

ブックマーク

Go 言語に関するブックマーク集はこちら。

ちなみに Go 言語の goto やラベル付きの break, continue は飛び先に制約があり，どこにでもジャンプできるわけではない。 ↩︎
例外を備える言語でこれを緩和する仕様はいくつかある。例えば Java は 1.7 から try-with-resources 構文を導入した。もちろんこの構文を有効にするためには対象となるオブジェクトがこの構文に対応した作りになっていなければならない。 ↩︎
いや，ファイル・オープンのエラーを無視したらダメです（笑） ↩︎
Defer 構文で指定された処理は return 時に起動することが保証される。したがって，エラー発生時にはその都度 return で抜けて問題ない。むしろ goto や break で強制的に処理を抜けるよりは処理を分割して return で安全に処理を抜ける方法がないか検討すべきである。なお os.Exit() などで強制終了した場合は， Defer 構文で指定した処理は起動しないので注意。 ↩︎
いわゆる「文芸的プログラミング」とは異なるけど。紛らわしくてゴメン。 ↩︎
これからのコードは「文芸的」であることが必要条件だと思う。何故ならエンジニアにとって最も信頼できる「設計書」は（動いている）コードだからだ。コードをひとりで考えてひとりで書いてひとりで使ってひとりでメンテナンスするなら（本人さえ理解していれば）文芸的である必要はないかもしれない。が，実用的なコードでそんな状況はもはやありえない。コードにおいても暗黙知をできるだけ排除していくことが重要。 ↩︎
error は組み込み型。組み込み型や組み込み関数（append() とか）は builtin パッケージに定義が記述されているが，実際にこのパッケージを import して使うわけではない。 ↩︎
Recover は Defer 構文とともに使用する。つまり Panic 発生時でも Defer 構文で予約された処理は実行される。 ↩︎
これ以外にサーバ用途などでプロセスを落とせない場合に Recover で回避することもあるが，既に続行不可能な状態で無理やりプロセスを続行するのが正しい動きなのかどうかは疑問が残る。 ↩︎
それでもやっぱり nil は nil として扱ってほしいのだが。 ↩︎