As discussed in #537, to implement this functionality we need to add a ResultHasError function to the Function type in the orchestrion project and modify the dd-trace-go repository to make use of it.
I'm opening this issue to propose the ResultHasError function.
If there are no objections, I'd like to work on this.
Implementation
func (f *Function) ResultHasError() string {
// First, check for the most common case: a result of type "error"
for _, result := range f.Results {
if result.Type.String() == "error" {
return result.Name
}
}
// For other error types, only then check with types.Implements
for _, result := range f.Results {
if types.Implements(result.Type, errorInterface) {
return result.Name
}
}
return ""
}
I haven't run any benchmarks, but I believe a simple string comparison is much faster than using the types.Implements method, and since most users are likely using the native error type, checking for that first before falling back to types.Implements seems like a good approach.
Would it be acceptable to proceed with a PR using code similar to the above?
Additionally, the corresponding Issue for dd-trace-go can be found here: DataDog/dd-trace-go#3168
As discussed in #537, to implement this functionality we need to add a
ResultHasErrorfunction to the Function type in theorchestrionproject and modify thedd-trace-gorepository to make use of it.I'm opening this issue to propose the
ResultHasErrorfunction.If there are no objections, I'd like to work on this.
Implementation
I haven't run any benchmarks, but I believe a simple string comparison is much faster than using the
types.Implementsmethod, and since most users are likely using thenative error type, checking for that first before falling back totypes.Implementsseems like a good approach.Would it be acceptable to proceed with a PR using code similar to the above?
Additionally, the corresponding Issue for dd-trace-go can be found here: DataDog/dd-trace-go#3168