Repository navigation
Feature Request: buildTraceTree can use interface to get program counters from custom errors #104
Description
Currently, if I have a chain of errors including a custom error type that contains a program counter, it will not be included in the errtrace when I call errtrace.Format(w io.Writer, target error)
For example, I would like to make a custom error:
type myTraceableError struct {
// Machine-readable error code.
Code string
// Human-readable message.
Message string
// Logical operation and nested error.
Op string
// Wrapped Error
err error
// PC is the program counter for the location in this frame.
// For a frame that calls another frame, this will be the
// program counter of a call instruction. Because of inlining,
// multiple frames may have the same PC value, but different
// symbolic information.
pc uintptr
}
func (e *myTraceableError) CallerPC () uintptr {
return e.pc
}
If there was a defined interface that I could implement on this error so that buildTraceTree could use it to obtain the pc, this would allow me to use errtrace library with custom errors.
type CallerPCer interface {
CallerPC() uintptr
}
Activity
abhinav commentedon May 4, 2024
Hello!
I agree, this is a reasonable feature to support.
The interface shape is reasonable, although I'm still mulling over the naming.
Open to thoughts from others on this as well.
StevenACoffman commentedon May 4, 2024
Yeah, I don't love the name either, or I'd have gone ahead and submitted the PR. I had
Caller()but that made the interfaceCallererwhich looked strange. I had tried justPC()/PCerbut that was kind of an obscure acronym. If you eventually want to expose a method to return the Error Trace as a string or something, I don't want to squat onErrorTraceespecially since this isn't really that.Maybe
TraceCall()/TraceCallerwould be better?prashantv commentedon May 4, 2024
I like
CallerPC() uintptras a method. Are there cases where supporting[]uintptrcould be useful (that could beCallerPCs)StevenACoffman commentedon May 5, 2024
Another naming possibility is that the interface could be:
@prashantv I don't think supporting
[]uintptrwould be useful outside of constructing a stacktrace, since an error is actually a tree sinceerrors.Joinwas introduced.abhinav commentedon May 5, 2024
One thing worth mentioning as we’re brainstorming:
We could also take the errors.Unwrap approach: pick a good name for the method but don’t export an interface. Eg “if an error object implements ‘PC() uintptr’, […]”
Add TraceCaller interface for extensibility for #104 (#106)