Robust Error Tracking and Reporting in Go

Error handling is crucial for building reliable Go applications. This challenge focuses on implementing a system that not only handles errors gracefully but also tracks and reports them in a structured manner, allowing for easier debugging and monitoring. You'll build a simple error tracking service that logs errors with context and potentially sends them to a centralized reporting system (simulated here).

Problem Description

You are tasked with creating a Go package named errtrack that provides a mechanism for tracking and reporting errors within an application. The package should include:

1. TrackError(err error, context string) Function: This function takes an error and a context string as input. It should log the error and context to standard error (for demonstration purposes – in a real application, this would be a more sophisticated logging system). It should also return a modified error that includes the context.

2. ReportError(err error) Function: This function takes an error as input. It should extract the context from the error (if present – see point 1) and simulate sending the error and context to a centralized error reporting system (again, for demonstration, just print to standard error). If no context is present, it should simply print the error.

3. Contextual Error Type: Define a custom error type ContextualError that embeds the standard error interface and adds a Context field (string). This will allow you to attach context information to errors.

4. Error Wrapping: The TrackError function should wrap the original error with the ContextualError type, ensuring that the context is preserved throughout the error chain.

Expected Behavior:

• TrackError should log the error and context to standard error.
• TrackError should return a new error of type ContextualError containing the original error and the provided context.
• ReportError should extract and log the context (if available) along with the error to standard error.
• If an error is passed to ReportError that is not a ContextualError, it should simply log the error itself.

Edge Cases to Consider:

• What happens if TrackError is called with a nil error? (Should handle gracefully, likely by logging a message and returning nil).
• What happens if ReportError is called with a nil error? (Should handle gracefully, likely by doing nothing).
• How to handle errors that are already wrapped (e.g., using fmt.Errorf with %w)? The TrackError function should be able to handle these and still extract the context.

Examples

Example 1:

Input: err := errors.New("database connection failed"); context := "User Authentication"; err = errtrack.TrackError(err, context)
Output: (printed to stderr) "Error: database connection failed, Context: User Authentication"

Explanation: The TrackError function logs the error and context, and returns a ContextualError.

Example 2:

Input: errtrack.ReportError(err) // where err is the result of Example 1
Output: (printed to stderr) "Error: database connection failed, Context: User Authentication"

Explanation: The ReportError function extracts and logs the context from the ContextualError.

Example 3:

Input: err := errors.New("file not found"); errtrack.ReportError(err)
Output: (printed to stderr) "Error: file not found"

Explanation: The ReportError function logs the error because it's not a ContextualError.

Constraints

• The TrackError function must not modify the original error object passed to it. It must create a new error.
• The ReportError function should handle both ContextualError and standard error types gracefully.
• The solution must be implemented in Go.
• The code should be well-documented and easy to understand.
• The solution should be efficient; avoid unnecessary allocations or computations.

Notes

• Consider using Go's error wrapping capabilities (fmt.Errorf with %w) to preserve the original error while adding context.
• Think about how to handle errors that are already wrapped. You might need to unwrap the error to access the underlying error and its context.
• This is a simplified simulation of error tracking. In a real-world scenario, you would likely integrate with a dedicated error tracking service (e.g., Sentry, Rollbar). The logging to standard error is just a placeholder.
• Focus on the core functionality of tracking and reporting errors with context. Don't worry about complex features like error aggregation or deduplication.