[BUG][GO][Client] Returned err is never nil

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What’s the actual output vs expected output?

Description

When calling any generated Execute() function, a non-nil error is always returned. Instead of using the usual Go idiom:

result, _, err := r.Execute()
if err != nil {
	/* deal with error */
}

I need to check the actual error message in order to detect errors:

result, _, err := r.Execute()
if err != nil && err.Error() != "" {
	/* deal with error */
}

openapi-generator version

c3220848 (current main branch)

Related issues/PRs

I believe this was introduced by #8137. Maybe it is intended behaviour. Care to weigh in here, @code-lucidal58?

Suggest a fix

Successful execution of *Execute() should not return a non-nil error.

[cheshir]

@code-lucidal58, the semantic of golang error will be broken. Some part of the community uses codegen to generate wrappers around the API clients for writing logs, metrics, traces etc. They highly depend on the error type. E.g. gowrap template for opentracing.

Let’s look closer to the idea of returning error type: If you care about readability – we can use a helper function to extract necessary data using type assertion. If you care about performance – I’m sure that single type assertion Is not the main performance issue in call processing.

It would be great to hear thoughts of the other community members.

[zippolyte]

I’m in favor of reverting to the previous behaviour to keep the semantics of golang error.

I think the helper function is a good way to improve readability and avoid too many code duplications when dealing with errors. This is what is done in our terraform provider for instance, which uses a generated go client:

Cheers