Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop automatic prefix in error messages returned by Run()? #383

Closed
jotaen opened this issue Oct 6, 2023 · 2 comments · Fixed by #384
Closed

Drop automatic prefix in error messages returned by Run()? #383

jotaen opened this issue Oct 6, 2023 · 2 comments · Fixed by #384

Comments

@jotaen
Copy link
Contributor

jotaen commented Oct 6, 2023

It seems that all error messages, which are returned by a Run() method of a command struct, are prefixed with the call chain of the program.

Consider the following sample program:

package main

import (
	"errors"
	"fmt"
	"github.com/alecthomas/kong"
)

type Context struct {}

type Cmd struct {}

func (c *Cmd) Run(ctx *Context) error {
	return errors.New("Command failed.")
}

var cli struct {
	Cmd Cmd `cmd:"" default:"1"`
}

func main() {
	ctx := kong.Parse(&cli)
	err := ctx.Run(&Context{})
	if err != nil {
		fmt.Println(err)
	}
}

In my application, the error messages returned by Run() are end-user facing, so the “call-chain” prefix wouldn’t mean anything to my users and might potentially confuse them.

Would it be possible to drop the prefixing, and just pass on the original error object as is? I.e., without wrapping, modifying, or re-serializing the error object at all?

It seems that the new behaviour was introduced in #344, where callbacks.go now re-serializes the original error message, in order to add the prefix info:

return fmt.Errorf("%s.%s(): %w", v.Type(), name, err)

@alecthomas
Copy link
Owner

Yeah I'm honestly not sure why I added that at all. Want to send a PR?

@jotaen
Copy link
Contributor Author

jotaen commented Oct 7, 2023

Sure → #384

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants