Go における「if err != nil」エラーハンドリング

JPKODA 編集部 May 9, 2026

他の言語で好まれる try-catch による例外（Exception）の投げ合いとは異なり、Go言語は明示的かつ直接的なエラーハンドリングを推奨しています。この哲学を実現するための核心的な武器こそが、至る所に登場する if err != nil ブロックです。

一見すると冗長に思えるこのパターンですが、実のところGo言語の精髄の一つです。開発者に失敗の可能性（Error）があるすべてのオペレーションと向き合うことを強制し、エラー処理をビジネスロジックの中で明確に可視化させることで、プログラムの透明性とメンテナンス性を劇的に向上させています。

本章では、if err != nil を極めるための手法について深く掘り下げていきます。

1. error型とif err != nilの再確認

前章で述べた通り、error はGoの組み込みインターフェース（Interface）です。ファンクション（Function）が実行に失敗する可能性がある場合、通常は最後の戻り値（Return Value）として error を返します。

すべてが正常であれば、nil を返します。
問題が発生した場合は、具体的なエラー情報を含んだオブジェクトを返します。

したがって、if err != nil はそのオペレーションが成功したかどうかを判断する「検問所」の役割を果たします。

1.1 実戦ケース：ファイルの読み込み

実際にファイルを読み込む際、この「検問所」がどのように機能するかを見てみましょう。

package main

import (
	"fmt"
	"log"
	"os"
)

func main() {
	// ファイルの読み込みを試行。os.ReadFile はバイトスライスとエラーを返します。
	content, err := os.ReadFile("myfile.txt")
		
	// 第一にセキュリティチェック（エラー確認）を実行！
	if err != nil {
		// エラーが発生した場合（ファイルが存在しない、権限不足など）、即座に処理します。
		// log.Fatal はエラーを出力し、プログラムを直ちに終了させます。
		log.Fatal("ファイルの読み込みに失敗しました:", err)
	}
		
	// 検問を通過した場合（err が nil の場合）のみ、content データを使用できます。
	fmt.Printf("ファイル内容: %s\n", content)
}

1.2 実戦ケース：データ型の変換

ユーザーが入力した文字列（String）を数値（Integer）に変換する、非常に頻度の高いシーンを見てみましょう。

package main

import (
	"fmt"
	"strconv"
)

func main() {
	numberString := "123a" // 意図的に不正な数字文字列を用意
		
	// strconv.Atoi は文字列を整数に変換しようと試みます
	number, err := strconv.Atoi(numberString)
		
	// 検問所：変換が成功したかチェック
	if err != nil {
		fmt.Println("形式エラー。整数に変換できません:", err)
		return // 早期リターン (Early Return) により、エラーの蔓延を阻止
	}
		
	// 安全圏：ここに来れば、安心して number を使用できます
	result := number * 2
	fmt.Println("計算結果:", result)
}

2. if err != nil の核心心得とベストプラクティス

エラーハンドリングをエレガントに記述するためには、以下の重要な原則をマスターする必要があります。

2.1 エラーを絶対に無視しない (Don't Ignore Errors)

これはGoプログラマにとっての第一戒律です。空白識別子 _ を使って error を受け取り、そのまま破棄することは絶対にしないでください。

もしエラーを無視して、プログラムが不完全な状態（State）のまま強引に動作を続ければ、最終的には極めて奇妙でデバッグが困難なパニック（Panic）によるクラッシュを引き起こすことになります。

2.2 早期リターン (Early Return) とインデントの削減

if err != nil を記述する際、エラー処理が終わったら即座に return するべきです。これにより、正常なロジックを処理するために深い else のネスト（Nest）を書くことを避け、コードをすっきりとした「左揃え」のスタイルに保つことができます。

避けるべき書き方 (アロー型コード):

data, err := doSomething()
if err == nil {
    result, err2 := doAnotherThing(data)
    if err2 == nil {
        // 正常なロジックがどんどん深くネストしていく...
    } else {
        return err2
    }
} else {
    return err
}

推奨される書き方 (早期リターン、ガード句):

data, err := doSomething()
if err != nil {
    return err // エラーを発見したら即座に終了
}

result, err2 := doAnotherThing(data)
if err2 != nil {
    return err2 // エラーを発見したら即座に終了
}

// すべての関門を突破。正常なロジックは最外層に保たれ、非常にクリア！
return result, nil

2.3 エラーにコンテキスト (Context) を追加する

深い階層のファンクションでエラーをインターセプトし、それを上位レイヤーに返す際、return err とそのまま返してはいけません。

fmt.Errorf("...: %w", err) を使用して、そのファンクションが「何をしている時に失敗したのか」という説明を付加し、エラーに「外装」を着せてください。これは本番環境でのトラブルシューティングにおいて非常に大きな価値を持ちます。

package main

import (
	"fmt"
	"os"
)

func loadConfig(filename string) ([]byte, error) {
	content, err := os.ReadFile(filename)
	if err != nil {
		// 🌟 ベストプラクティス：エラーをラッピングし、loadConfig 時のファイル読み込み失敗であることを明示
		return nil, fmt.Errorf("loadConfig 失敗。ファイル %s を読み込めません: %w", filename, err)
	}
	return content, nil
}

3. エラーハンドリングのベストパートナー：defer ステートメント

詳細な defer の使い方は後続のアドバンス章で解説しますが、エラーハンドリングとの相性は抜群です。

ファンクションがファイルを開いたり、データベース（Database）接続を確立したりした場合、その後の操作で error が発生して途中で return したとしても、リソース（Resource）が正しく解放されることを保証しなければなりません。defer はそのために存在します。

package main

import (
	"fmt"
	"os"
)

func processFile() error {
	file, err := os.Open("data.csv")
	if err != nil {
		return fmt.Errorf("ファイルオープン失敗: %w", err)
	}
		
	// 🌟 defer は file.Close() を現在の関数 processFile が終了する直前まで実行を遅延させます。
	// 下記のコードが正常に終わっても、err != nil で早期リターンしても、必ず実行されることが保証されます！
	defer file.Close() 
		
	// ... ファイル読み込みのロジック ...
	// ここでもしエラーが発生したと仮定します
	// return fmt.Errorf("データ解析失敗") 
		
	return nil
}

最後に、panic と recover について覚えておいてください。Go言語において、通常のビジネスエラー（パスワード間違い、ファイルが見つからないなど）に panic を使用すべきではありません。panic は、「天が落ちてきた」かのような、プログラムがもはや継続不可能な致命的なバグ（配列のインデックス範囲外、空ポインタ例外など）にのみ使用されます。日常の開発では、しっかりと if err != nil を抱きしめて実装していきましょう。