Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions rules/S8212/go/metadata.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
{
"title": "Error messages should include all available error information",
"type": "CODE_SMELL",
"status": "ready",
"remediation": {
"func": "Constant/Issue",
"constantCost": "5 min"
},
"tags": [
"error-handling",
"debugging"
],
"defaultSeverity": "Blocker",
"ruleSpecification": "RSPEC-8212",
"sqKey": "S8212",
"scope": "All",
"defaultQualityProfiles": [
"Sonar way"
],
"quickfix": "unknown",
"code": {
"impacts": {
"MAINTAINABILITY": "BLOCKER"
},
"attribute": "COMPLETE"
}
}
69 changes: 69 additions & 0 deletions rules/S8212/go/rule.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
This rule raises an issue when error reporting functions include only partial error information while additional error details are available in scope.

== Why is this an issue?

When errors occur, complete information is essential for effective debugging. Including only partial error details, such as error types or contexts, while omitting the actual error values makes troubleshooting significantly more difficult.

In Go, errors often contain specific details about what went wrong, including stack traces, underlying causes, and contextual information. When developers report errors using functions like `t.Fatalf()`, `log.Printf()`, or similar logging mechanisms, they sometimes include only generic error types (like `context.DeadlineExceeded`) or partial context, while the actual error variable containing detailed information remains unused.

This practice creates several problems:

* **Incomplete debugging information**: Developers trying to fix issues lack the specific details needed to understand the root cause
* **Increased debugging time**: Without complete error information, developers must spend additional time reproducing issues or adding more logging
* **Missed error patterns**: Specific error details might reveal patterns or common causes that generic error types don't show

Complete error reporting helps teams identify issues faster, understand their scope, and implement more targeted fixes.

=== What is the potential impact?

Incomplete error reporting significantly increases debugging time and effort. Developers may struggle to identify root causes of failures, leading to longer resolution times and potentially missing critical issues. In production environments, this can result in prolonged outages or unresolved problems that affect system reliability.

== How to fix it

Include all available error information in error messages. When both error context and error variables are available, include both in the error message to provide complete debugging information.

=== Code examples

==== Noncompliant code example

[source,go,diff-id=1,diff-type=noncompliant]
----
func processWorkflow() {
err := executeWorkflow()
if err != nil {
t.Fatalf("executeWorkflow error: %v", context.DeadlineExceeded) // Noncompliant
}
}
----

==== Compliant solution

[source,go,diff-id=1,diff-type=compliant]
----
func processWorkflow() {
err := executeWorkflow()
if err != nil {
t.Fatalf("executeWorkflow error: %v, err: %v", context.DeadlineExceeded, err)
}
}
----

== Resources

=== Documentation

* Go Error Handling - https://go.dev/blog/error-handling-and-go[Official Go blog post about error handling best practices]

* Effective Go - Errors - https://go.dev/doc/effective_go#errors[Official Go documentation on error handling patterns]

* Go Testing Package - https://pkg.go.dev/testing[Documentation for Go's testing package and error reporting functions]

=== Standards

* CWE-209: Generation of Error Message Containing Sensitive Information - https://cwe.mitre.org/data/definitions/209.html[While this rule promotes including more error information, care should be taken not to expose sensitive data]

=== Related rules

* RSPEC-2698 - https://rules.sonarsource.com/java/RSPEC-2698/[Java rule for including complete error information in test assertions]

* RSPEC-6423 - https://rules.sonarsource.com/csharp/RSPEC-6423/[C# rule for comprehensive error reporting in tests]
2 changes: 2 additions & 0 deletions rules/S8212/metadata.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
{
}