Go言語におけるエラーハンドリングのベストプラクティス

Goにおけるエラーハンドリングの重要性と設計の基本原則

Go言語で構築されるシステムの信頼性は、エラーハンドリングの設計品質に大きく依存します。特に大規模なシステムでは、予期せぬエラーが発生した際に適切に対処できないと、リソースリークやデータ破損、最悪の場合サービス停止に至る可能性があります。また、panicという強力だが危険な機能を誤って使用してしまうと、デバッグ困難なランタイムエラーが発生します。

この記事では、Go言語においてエラーハンドリングを設計する際の基本原則や実践的なベストプラクティスを解説します。具体的には、errorとpanicの使い分け、レイヤーごとの責任分離、カスタムエラーの設計方法、ユーザー向けエラーメッセージの作成、そしてテストでの検証ポイントなど、実務で即活かせる知識を体系的にまとめます。

errorとpanicの使い分け方（致命的エラー対応策）

Go言語では、非致命的なエラーはerror型で処理し、致命的なエラーはpanicでハンドリングするという原則があります。この使い分けが適切でない場合、システムの信頼性や保守性に深刻な影響を与えるため、その設計基準を明確化します。

非致命的エラーの処理フロー

Go言語では、error型を使ってリカバリ可能な状態を伝達するのが一般的です。たとえば、ファイル読み込みやネットワーク接続時のエラーコードは、if err != nilで検出後、適切なフォールバック処理（再試行・代替データの使用など）を行うべきです。

• 処理フロー例:
  go
file, err := os.Open("data.txt")
if err != nil {
// エラーログ出力
log.Printf("ファイル読み込みエラー: %v", err)
return nil, fmt.Errorf("ファイル読み込み失敗: %w", err)
}
defer file.Close()

このように、error型を使用することで、呼び出し元に原因を明確に伝達し、状況に応じた処理が可能になります。

不可逆的エラーにおけるpanicの適切な使用ケース

一方で、システムの安全性に直接影響する致命的なエラー（例: データベース接続失敗・セキュリティ侵害など）では、panicを適切に使用することがあります。ただし、これは「最後の手段」であり、以下の条件が満たされる場合のみ許容されます。

blockquote
panicはあくまで最後の手段であり、過剰な使用はデバッグ困難な状態に陥る原因になります。セキュリティ侵害などのケースでは、単なるpanicではリスクを完全に抑えることはできず、ログ出力・監視アラート・回復処理の実装も併せて行う必要があります。

レイヤーごとの責任分離によるエラーハンドリング設計

アプリケーションの信頼性を高めるためには、各レイヤーが自身の責任範囲内でエラーを適切に処理し、外部に伝達する仕組みが必要です。

ビジネスロジック層でのエラー隠蔽

各レイヤー（データアクセス層、ビジネスロジック層、プレゼンテーション層）では、自分専用のエラータイプを定義し、責任範囲内でのみ処理を行うべきです。例えば、DB接続エラーはデータアクセス層でerrorとして返却し、ビジネスロジック層では受け取ったエラーを別のエラータイプに変換して返すと良いでしょう。

• 例: エラー隠蔽の実装
  go
// データアクセス層のエラー型
type DataAccessError struct {
Message string
Code int
}

// ビジネスロジック層での処理
func ProcessOrder(order Order) error {
dataErr := fetchData(order.ID)
if dataErr != nil {
return &BusinessLogicError{
Cause: dataErr,
Code: 503,
Message: "データ取得に失敗しました",
}
}
// 継続処理
}


API階層での統一エラーコード化

API設計では、ユーザー向けのエラーコードを標準化する必要があります。たとえば、HTTPステータスコードやカスタムエラーコードを用いて、エラー内容を明確に伝達します。

• 統一エラーコード例:
  go
// カスタムエラータイプの定義
type APIError struct {
Code int
Message string
}

// HTTPレスポンス生成例
func HandleRequest(w http.ResponseWriter, r *http.Request) {
err := internalProcessing()
if err != nil {
apiErr := &APIError{
Code: http.StatusInternalServerError,
Message: "内部エラーが発生しました",
}
w.WriteHeader(apiErr.Code)
fmt.Fprintf(w, "%s", apiErr.Message)
}
}


カスタムエラー型の設計パターンと実装

状態情報付きエラーインターフェース

Goではerrorインタフェースを実装することで、カスタムエラータイプを作成できます。これは、状態（コード・メッセージ）や原因エラーを含む情報を伝達するのに有効です。

• カスタムエラータイプの定義:
  go
type ValidationFailure struct {
Field string
Message string
}

func (e *ValidationFailure) Error() string {
return fmt.Sprintf("%s: %s", e.Field, e.Message)
}


blockquote
errorインターフェースは、状態情報を含むエラーを一貫して扱えるようにする設計の基盤です。さらに、fmt.Errorfやerrors.Newによるラッピングも可能です。

複数エラーの処理戦略

複数のエラーを一度に処理する必要がある場合、errors.Join()やfmt.Errorfでerrorをラップ（wrap）することが推奨されます。これにより、原因トレースが可能になります。

• 例: 複数エラーのラッピング:
  go
err1 := fmt.Errorf("ファイルオープン失敗: %w", os.ErrNotExist)
err2 := fmt.Errorf("処理中断: %w", err1)

ユーザーエクスペリエンスに配慮したエラー応答設計

内部エラーの隠蔽と抽象化

ユーザーは、システム内部の詳細なエラーメッセージを知る必要はありません。たとえば、データベース接続失敗などの内部エラーは「一時的な通信障害が発生しました」と伝えることで、混乱を防げます。

• 抽象化されたユーザー向けメッセージ例:
  go
func HandleInternalError(err error) string {
return "システムの不具合により処理できませんでした。しばらくしてから再度お試しください"
}

エラーメッセージの国際化対策

グローバルなユーザー層を持つアプリケーションでは、エラーメッセージを多言語対応する必要があります。Goではi18nなどのライブラリを使ってメッセージを切り替え可能です。

• 国際化実装例（拡張版）:
  go
var messages = map[string]map[string]string{
"ja": {
"data_not_found": "データ取得に失敗しました。",
"system_error": "システムの不具合により処理できませんでした。",
},
"en": {
"data_not_found": "Failed to retrieve data.",
"system_error": "Internal error occurred. Please try again later.",
},
}

func GetLocalizedMessage(lang, key string) string {
if msg, ok := messages[lang][key]; ok {
return msg
}
return "Unknown error"
}


blockquote
国際化実装では、言語切り替えロジックやメッセージの管理方法に加え、デフォルト言語の設定・未翻訳メッセージへの対応策も考慮する必要があります。

テストにおけるエラーハンドリング検証のポイント

正常系/異常系のカバレッジ確保

単体テストでは、正常なケースとエラー発生時の処理を共に検証する必要があります。Goでこれを実現するには、mockやstubライブラリ（gomock, testifyなど）が有効です。

• 例: 異常系テストの構成:
  go
func TestProcessWithMockError(t *testing.T) {
mockService := new(MockDataAccess)
mockService.On("Fetch", "123").Return(nil, errors.New("mock error"))

  result, err := ProcessOrder("123", mockService)
assert.Error(t, err)
assert.Equal(t, "データ取得に失敗しました", err.Error())
}


パニック発生時のテストアサーション

panicが適切にハンドルされているかは、テストで明示的に検証する必要があります。Goではrecover()と組み合わせて、パニックを捕捉してアサーションできます。

• 例: panicのテスト:
  go
func TestPanicRecovery(t *testing.T) {
defer func() {
if r := recover(); r != nil {
assert.Equal(t, "致命的エラー: データベース接続失敗", r)
} else {
t.Fail()
}
}()
triggerPanic() // あえてpanicを発生させる
}

func triggerPanic() {
panic("致命的エラー: データベース接続失敗")
}