Go Error Wrapping: Adding Context to Failures

In Go, errors are first-class citizens, but often, a simple error message isn't enough to diagnose the root cause of a problem. This challenge focuses on implementing robust error wrapping, allowing you to chain errors together and add contextual information as errors propagate through your application. This practice is crucial for effective debugging and understanding the lifecycle of an error.

Problem Description

Your task is to implement a system for wrapping Go errors with additional context. You need to create a function that takes an original error and some contextual information (e.g., an operation name, a specific value) and returns a new error that encapsulates the original error along with this new context. The wrapped error should allow for inspection of its underlying cause and the contextual information it carries.

Key Requirements:

• Create a function, let's call it WrapError, that accepts an error and a string representing context.
• The WrapError function should return a new error type that stores both the original error and the provided context.
• The returned error should implement the Error() method, providing a user-friendly string representation that includes the context and the original error's message.
• The returned error should also implement the Unwrap() method (available since Go 1.13) to allow inspection of the underlying error.
• You should also implement a way to check if a wrapped error contains a specific underlying error type or a specific error message.

Expected Behavior: When an error is wrapped multiple times, each layer of context should be preserved. Debugging tools and logging mechanisms should be able to traverse the chain of wrapped errors to understand the full sequence of events leading to the failure.

Edge Cases to Consider:

• Wrapping a nil error: The function should handle this gracefully.
• Wrapping an error multiple times: Ensure the Unwrap() chain works correctly.
• Checking for specific errors in a deeply nested error chain.

Examples

Example 1:

originalErr := errors.New("file not found")
wrappedErr := WrapError(originalErr, "reading config file")

fmt.Println(wrappedErr.Error())
// Expected Output: "reading config file: file not found"

Explanation: The WrapError function creates a new error that prepends the context string to the original error's message.

Example 2:

originalErr := errors.New("database connection failed")
step1Err := WrapError(originalErr, "initializing database")
step2Err := WrapError(step1Err, "connecting to primary server")

fmt.Println(step2Err.Error())
// Expected Output: "connecting to primary server: initializing database: database connection failed"

unwrappedErr := errors.Unwrap(step2Err)
fmt.Println(unwrappedErr.Error())
// Expected Output: "initializing database: database connection failed"

unwrappedUnwrappedErr := errors.Unwrap(unwrappedErr)
fmt.Println(unwrappedUnwrappedErr.Error())
// Expected Output: "database connection failed"

Explanation: This demonstrates multiple levels of error wrapping and the correct behavior of errors.Unwrap() to traverse the chain.

Example 3: (Checking for specific errors)

// Assume a custom error type
type PermissionError struct {
    Resource string
}
func (e *PermissionError) Error() string {
    return fmt.Sprintf("permission denied for resource: %s", e.Resource)
}

originalErr := &PermissionError{Resource: "user_data"}
wrappedErr := WrapError(originalErr, "accessing user profile")

if errors.Is(wrappedErr, originalErr) { // Checking for the exact original error instance
    fmt.Println("Found the original error instance!")
}

// If we had a custom error checker, it would look something like this conceptually:
// if HasErrorType[*PermissionError](wrappedErr) {
//     fmt.Println("Found a PermissionError in the chain!")
// }

Explanation: This example hints at the need for error checking functions like errors.Is and errors.As (from Go 1.13+) to inspect the error chain. You will need to implement a way to check for specific types of errors within the wrapped chain.

Constraints

• Your custom error type must implement the error interface.
• Your custom error type must implement the Unwrap() error method.
• Your solution should use standard Go libraries where possible.
• The WrapError function should be efficient and not introduce significant overhead.

Notes

Consider using the errors package (specifically errors.New, errors.Unwrap, errors.Is, errors.As) which was introduced in Go 1.13. Your implementation should be compatible with and leverage these standard library features. Think about how your custom error type can expose the original error and its own contextual data.