SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
Go

Go static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your GO code

  • All rules 94
  • Vulnerability21
  • Bug13
  • Security Hotspot14
  • Code Smell46
Filtered: 3 rules found
error-handling
    Impact
      Clean code attribute
        1. Custom error types must implement "Error()" method correctly

           Bug
        2. Functions should follow Go's explicit error handling patterns

           Code Smell
        3. Delivering code in production with debug features activated is security-sensitive

           Security Hotspot

        Custom error types must implement "Error()" method correctly

        intentionality - logical
        reliability
        maintainability
        Bug
        • error-handling

        This rule raises an issue when a custom type intended to be used as an error either lacks an Error() method implementation or implements it in a way that causes infinite loops.

        Why is this an issue?

        How can I fix it?

        More Info

        In Go, the error type is a built-in interface that requires a single method:

        type error interface {
            Error() string
        }
        

        When you create a custom type to represent errors, you must implement this Error() method to satisfy the interface. Without it, your type cannot be used as an error, leading to compilation errors or runtime panics.

        A common mistake when implementing the Error() method is calling formatting functions like fmt.Sprint(), fmt.Sprintf(), or fmt.Print() directly on the receiver. This creates an infinite loop because these formatting functions automatically call the Error() method when they encounter a type that implements the error interface.

        Here’s what happens in the infinite loop:

        1. Your Error() method calls fmt.Sprint(e)
        2. fmt.Sprint() sees that e implements the error interface
        3. fmt.Sprint() calls e.Error() to get the string representation
        4. This calls your Error() method again, creating an endless cycle

        This infinite recursion will cause a stack overflow and crash your program.

        What is the potential impact?

        Missing or incorrectly implemented Error() methods can cause:

        • Compilation failures when trying to use the custom type as an error
        • Runtime panics due to stack overflow from infinite recursion
        • Application crashes that are difficult to debug
        • Poor error handling that makes troubleshooting harder for users and developers
          Available In:
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

        © 2025 SonarSource Sàrl. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use