proposal: error handling:

[thorntonrose]

Proposal Details

Would you consider yourself a novice, intermediate, or experienced Go programmer?

Experienced.

What other languages do you have experience with?

Java, Groovy, Python, Erlang, Ruby, Delphi, FoxPro, C/C++, and others.

Would this change make Go easier or harder to learn, and why?

Neither. No language changes are included in this proposal.

Has this idea, or one like it, been proposed before?

Not that I am aware of.

What is the proposed change?

Simply say, in documentation and training materials (e.g. "Effective Go", "Go Style Best Practices"), that panic/recover is as acceptable as returning errors.

Is this change backward compatible?

Yes. No language changes are required.

Examples:

Idiomatic / good style:

func GetProfile(req Request) (Response, error) {
   user, err := db.GetUserById(req.Id)

   if err != nil {
      return Response{}, err
   }

   settings, err := db.GetSettingsById(req.Id)

   if err != nil {
      return Response{}, err
   }

   return Response{User: user, Settings: settings}, nil
}

Also idiomatic / good style:

func GetProfile(req Request) (resp Response, err error) {
   defer func() {
      if r := recover(); r != nil {
         err = fmt.Errorf("get profile: %w", r)
      }
   }()

   resp.User := db.GetUserById(req.Id)
   resp.Settings := db.GetSettingsById(req.Id)

   return resp, err
}

package db

...

func GetUserById(id string) User {
   user := ...

   if user == nil {
      panic(fmt.Errorf("user not found: %s", id))
   }

What is the cost of this proposal?

Minimal. Only documentation and training materials would need to be updated.

Can you describe a possible implementation?

N/A

How would the language spec change?

N/A

Orthogonality: how does this change interact or overlap with existing features?

N/A

Is the goal of this change a performance improvement?

No.

Does this affect error handling?

In the language, no. In solutions, perhaps.

*Is this about generics?

No.

Conclusion:

Panic and recover are features of the language. There is no reason that using them should be any less valid than using any other language feature. Making panic/recover as acceptable as returning errors would make error handling a less contentious subject and greatly reduce the desire of many programmers to "fix" it (or to just stop using Go).

[gabyhelp]

Similar Issues

• proposal: panic based error handling #36189
• Proposal: Panics returned as errors if the function has an error result type #32871
• proposal: Go 2: error handling with magic .handleErr() method #56126
• proposal: Go 2: use keywords throw, catch, and guard to handle errors #40583
• proposal: Go 2: return error on assignment to _ #65345
• proposal: Go 2: error handling with handle keyword and optional return of error type #54677
• proposal: Go 2: error handling: try statement with handler #56165
• proposal: Go2: error handling shortening #62378
• proposal: Go 2: Error-Handling Paradigm #60720
• proposal: Go 2: catch error handler #43777

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

[seankhliao]

See https://go.dev/blog/errors-are-values

[thorntonrose]

See https://go.dev/blog/errors-are-values

I have seen that, many times. Dogma is alive and well here.

[ianlancetaylor]

Go is an opinionated language.