高級進行錯誤處理技術

Go 的高級錯誤處理通過上下文包裝、自定義錯誤類型和集中化日誌提升系統可觀測性與可維護性。 1. 使用fmt.Errorf 的%w 包裝錯誤以保留原始信息並添加上下文，便於用errors.Is 和errors.As 進行判斷。 2. 定義包含錯誤碼、元數據和時間戳的自定義錯誤結構體（如AppError），支持結構化日誌和監控集成。 3. 使用哨兵錯誤（如ErrNotFound）表示可預期的特定狀態，並通過errors.Is 進行安全比對。 4. 利用errors.As 提取帶有行為或狀態的底層錯誤（如net.Error）以實現條件處理。 5. 在goroutine 中使用defer/recover 捕獲panic，防止程序崩潰，但應避免在庫代碼中濫用panic。 6. 通過結構化日誌庫（如zerolog）記錄錯誤鍊及上下文，並結合OpenTelemetry 等工具實現鏈路追踪。 7. 避免吞掉錯誤或重複包裝，確保每次錯誤處理只做一次包裝或新建操作。 8. 在HTTP 處理器中根據錯誤類型返回對應狀態碼，並可通過中間件統一映射錯誤響應。總結：高級錯誤處理強調上下文傳遞、分類清晰、可觀測性強，使簡單的error 模型支撐複雜系統，最終實現可調試、可恢復、易維護的服務架構。

Go's error handling is famously simple—return errors from functions and check them explicitly. But as applications grow in complexity, basic if err != nil checks aren't enough. To build robust, maintainable systems, you need advanced error handling techniques that improve observability, provide context, and support better debugging and recovery.

Here are key advanced patterns and practices used in production-grade Go services.

1. Wrapping Errors with Context (Go 1.13 )

One of the biggest limitations of early Go error handling was losing context. When an error is returned up the call stack, you often don't know where it originated or what led to it.

Go 1.13 introduced %w in fmt.Errorf to wrap errors, enabling both context addition and preservation of the original error for inspection.

 if err != nil {
    return fmt.Errorf("failed to process user %s: %w", userID, err)
}

Now, the returned error carries:

• A descriptive message indicating what went wrong.
• A wrapped original error for programmatic inspection.

You can later use errors.Is and errors.As to check for specific error types or values, even through layers of wrapping.

 if errors.Is(err, io.ErrUnexpectedEOF) {
    // Handle specific error, even if wrapped
}

 var pathErr *os.PathError
if errors.As(err, &pathErr) {
    log.Printf("File error on path: %s", pathErr.Path)
}

✅ Best Practice : Wrap errors at boundaries (eg, when crossing layers like DB → service → handler), but avoid wrapping the same error multiple times.

2. Custom Error Types with Structured Data

Sometimes you need more than a string—you want to attach metadata like error codes, timestamps, or request IDs.

Define custom error types:

 type AppError struct {
    Code string
    Message string
    Details map[string]interface{}
    Err error
    Time time.Time
}

func (e *AppError) Error() string {
    return e.Message
}

func (e *AppError) Unwrap() error {
    return e.Err
}

Usage:

 return &AppError{
    Code: "DB_TIMEOUT",
    Message: "database query timed out",
    Details: map[string]interface{}{"query": query, "duration": timeout},
    Time: time.Now(),
}

This enables:

• Centralized error logging with structured fields.
• Better integration with monitoring tools (eg, Sentry, Datadog).
• Conditional handling based on error code.

3. Error Classification and Sentinel Errors

Use sentinel errors for well-known conditions that callers may want to handle explicitly.

 var (
    ErrNotFound = errors.New("resource not found")
    ErrAlreadyExists = errors.New("resource already exists")
    ErrTimeout = errors.New("operation timed out")
)

These can be safely compared using errors.Is :

 if errors.Is(err, ErrNotFound) {
    // Handle missing resource
}

⚠️ Avoid exporting too many sentinels. Only do so when the error represents a meaningful, stable contract between packages.

4. Using Interface Assertions for Error Inspection

Some errors carry state or behavior. Use errors.As to extract them:

 var netErr net.Error
if errors.As(err, &netErr) && netErr.Timeout() {
    log.Println("Network timeout occurred")
}

This is especially useful when dealing with third-party libraries that return rich error types.

5. Recovery in Goroutines

Unrecovered panics in goroutines crash the entire program. Always wrap goroutine logic with defer/recover when appropriate:

 go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("Panic recovered: %v", r)
            // Optionally report to monitoring
        }
    }()
    // risky operation
}()

? Note: Use sparingly. Prefer proper error returns over panic in library code.

6. Centralized Error Logging and Monitoring

Use structured logging to capture errors with context:

 import "github.com/rs/zerolog/log"

if err != nil {
    log.Error().
        Err(err).
        Str("user_id", userID).
        Str("action", "update_profile").
        Send()
    return err
}

With wrapped errors, zerolog (and similar libraries) can automatically traverse the error chain and extract all messages and types.

Pair this with observability tools:

• Add error codes to logs for filtering.
• Use tracing (eg, OpenTelemetry) to link errors to requests.

7. Avoid Silent Error Swallowing and Blind Wrapping

Common anti-patterns:

 // BAD: Losing information
if err != nil {
    return fmt.Errorf("failed") // No original error
}

// BAD: Double wrapping
if err != nil {
    return fmt.Errorf("failed: %w", fmt.Errorf("inner: %w", err)) // Redundant
}

Always either wrap or create a new error—don't do both.

8. Error Handling in HTTP Handlers

In web services, translate internal errors into appropriate HTTP responses:

 func handleUserGet(w http.ResponseWriter, r *http.Request) {
    user, err := userService.Get(r.Context(), userID)
    if err != nil {
        switch {
        case errors.Is(err, ErrNotFound):
            http.NotFound(w, r)
        case errors.As(err, new(*AppError)) && err.(*AppError).Code == "AUTH_FAILED":
            http.StatusUnauthorized(w, r)
        default:
            log.Err(err).Msg("internal server error")
            http.Error(w, "Internal error", http.StatusInternalServerError)
        }
        return
    }
    // send user
}

Consider using middleware to centralize error-to-HTTP mapping.

Summary

Advanced Go error handling is about:

• Preserving context via error wrapping ( %w ).
• Enriching errors with metadata using custom types.
• Classifying errors so callers can react appropriately.
• Observing errors through structured logging and monitoring.
• Handling panics safely in concurrent code.

Used wisely, these techniques turn Go's simple error model into a powerful tool for building resilient systems.

Basically, don't just return err —think about who will handle it, how they'll debug it, and what they'll do next.

以上是高級進行錯誤處理技術的詳細內容。更多資訊請關注PHP中文網其他相關文章！