Provide contextual error messages

Error messages should be specific, contextual, and use appropriate error creation functions to help users understand what went wrong and how to fix it.

Key principles:

1. Include relevant context: Error messages should contain specific identifiers, values, or context that help identify the source of the problem.

2. Use appropriate error creation functions:
   • Use errors.New() for static error messages without formatting
   • Use fmt.Errorf() only when you need to include dynamic values
   • Use trace-specific functions like trace.BadParameter() when appropriate
3. Be specific about the problem: Avoid generic messages that don’t help users understand what went wrong.

Examples:

// Bad: Generic error without context
return trace.BadParameter("target is not an IC plugin")

// Good: Specific error with context
return trace.BadParameter("%q is not an AWS Identity Center integration", p.edit.awsIC.pluginName)

// Bad: Using fmt.Errorf for static messages
return fmt.Errorf("end time before start time")

// Good: Using errors.New for static messages
return errors.New("end time before start time")

// Good: Using fmt.Errorf when formatting is needed
return fmt.Errorf("invalid request size: expected %d bytes, got %d bytes", requestHeaderSize, len(data))

This approach improves debugging experience by providing actionable information that helps users identify and resolve issues quickly.