Automatic Handling of Unchecked Errors in Go

[mole18]

Proposal Details

Background

In Go, error handling is typically done through return values. While this explicit error handling improves code readability, it can sometimes be verbose and prone to missing error checks.

Motivation

The current error handling mechanism requires developers to explicitly check errors every time a function that may return an error is called. This can lead to verbose code and increases the risk of overlooking error checks. Introducing a mechanism to automatically handle unchecked errors can simplify the code and enhance safety.

Proposal

Implement a feature at compile-time or runtime to automatically detect and handle unchecked errors. When a function call returns an error and that error is not explicitly handled, the compiler or runtime will automatically return the error to the caller.

Example

Copy Code
func inner() error {
    // Some operations that might fail
    return fmt.Errorf("some error")
}

func outer() error {
    // Current approach:
    // err := inner()
    // if err != nil {
    //     return err
    // }

    // Proposed approach:
    _ = inner() // Automatically handled by returning the error if not nil
}

Impact

Advantages

Simplified Code: Reduces repetitive error-checking code.
Reduced Oversight: Automatically handles unchecked errors, lowering the risk of missing error checks.

Potential Drawbacks

Debugging Complexity: Automatic error handling might complicate debugging as the error propagation path is no longer explicit.
Deviation from Current Practice: This approach differs from Go's current philosophy of explicit error handling, requiring developers to adapt.

Alternatives

Use linting tools to flag unhandled errors during development.
Introduce new language features, such as a try keyword, to simplify error handling.

Conclusion

By automatically handling unchecked errors at compile-time or runtime, the error handling process in Go can be simplified, reducing the risk of missing error checks.

[gabyhelp]

Related Issues

• proposal: handle error in minimal way #57552 (closed)
• proposal: Go 2: default error handling #24095 (closed)
• proposal: Proposal for Automatic Error Handling in Go #70151 (closed)
• proposal: Go 2: error handling with magic .handleErr() method #56126 (closed)
• proposal: Go 2: add try statement to specify handler for unhandled errors #35179 (closed)
• proposal: Go 2: error handling: set error as return value by default from function #39972 (closed)
• proposal: Go 1: Add error checking shorthand operator #58478 (closed)
• [Feature Request] Shorter error catching #18425 (closed)
• proposal: Go 2: use check error without handle #30680 (closed)
• proposal: Go 2: #54686 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

Duplicate of #65345