ansel1 / merry Goto Github PK

Sometimes, errors are passed from merry-aware code to merry-unaware code. If it's the unaware code which is responsible for printing the error, it won't print the details. Might be helpful to have a flag on the merry error which changes the behavior of Error() to return the same as merry.Details(e).

This came up in unit tests. I use an assertions library (testify) which checks for errors. If there's an error, it prints it. I end up having to wrap the assertion library in order to print out the full merry details of the error.

Thanks for the awesome go package! Do you have plans to support gRPC codes? This is an extension to the HTTP codes.

Ref: https://godoc.org/google.golang.org/grpc/codes

Add a new native merry error property: "cause". This would be another error. Useful when a library emits errors of fixed types, and wants to wrap errors from lower level libraries in its own error types without losing information.

Details() would be enhanced to print the stack of causes, perhaps labelling the innermost cause the "root cause".

Cause(err) would get the next error down the cause stack. RootCause(err) would get the deepest cause.

Could also consider enhancing Is(), or adding an alternate form, for comparing against any of the causes in the stack.

$ go get github.com/ansel1/merry
go get: github.com/ansel1/[email protected] updating to
        github.com/ansel1/[email protected] requires
        github.com/ansel1/merry/[email protected]: invalid version: unknown revision 000000000000

I also note that there is no v2 release tag yet (only beta). I'm guessing making a v2.0.0 release tag and updating the v1 go.mod to point to that release tag would fix it.

I'm not sure if replace tags work as expected when a module is being imported as a library.

Example: in a web app's controller, you want to raise an error with a user message. The internal error message should be same. Today, you need to make two calls with the same message argument to achieve this. Would be nice to express "use this message for the internal message and the user message".

There are a few approaches:

1. A set of methods which set both the internal and user message
2. A function which fetches the user message first, and falls back on the internal message if no user message is set
3. A function which fetches the internal error, and falls back on the user message if not set

I'm leaning towards three. Two seems wrong because the whole purpose of the "user message" property is for frameworks to ensure that error messages presented to end users have been explicitly approved for end user consumption.

append something to the existing error message
err.Append("something") should equate to "err.WithMessagef("%s: %s", err.Error(), "something")

Hi,

I feel like Location() should return an empty string if it's unknown where the error happened.

• It's the null value of strings
• A file with that name could actually exist (although unlikely)
• Naming a file "" is probably impossible everywhere
• Other functions like Stacktrace() return an empty string as well, not "no stacktrace" :)

What do you think?

For setting an error message which is suitable for display to an end user. Error() would fall back on UserMessage if no other message was set.

In 99536c2 you changed the nil value handling and added a test for this (TestNilValues). It contains the following line:

if Wrap(nil).WithHTTPCode(400).WithMessage("hey") { //...

Maybe I misunderstand your commit, but you can't call methods on "true" nil interfaces, can you?

http://play.golang.org/p/mmJoXJR9J1

Did you mean

if (WithMessage(WithHTTPCode(Wrap(nil), 400), "hey") != nil) { //...

(This will still crash since WithValue doesn't handle the nil from the Wrap call it does.)

When a merry error is first created, or first wrapped around an existing error, it would be cool to optionally invoke configurable a callback. This would allow users of merry to:

1. capture a different kind of stacktrace (e.g. sentry stacktraces)
2. attach other context information to the error.
3. send the error to a log or error capture system

Callbacks would be registered globally. They would be invoked whenever a new merry error is created, or when an error was wrapped with a merry error. They would be passed the current merry error, and a stackframe offset from where the merry error is being created, and would return a merry error.

Actual: fmt.Printf("%+v", merry.Errorf("%w", merry.New("boom"))) does not print a stacktrace
Expected: It should print a stacktrace. Maybe the stacktrace of the wrapped error.

This example reproduces the issue - https://go.dev/play/p/15d5C3TAbDh .

As far as I understand the code, merry.Wrap called by merry.Errorf does not wrap the argument if it finds an existing stack trace in its wrap chain. Since merry.New("boom") is in the chain, merry.Errorf just returns the result of fmt.Errorf . However, in that case, fmt.Printf("%+v") will not use the Formatter interface implementation in merry.

Workaround: add any value. merry.Errorf("%w", merry.New("boom"), merry.WithValue("foo", "bar")) works fine.

Would it be possible to add method to print error and registered details, but without stack trace?

We generally define constants for often-used errors:

var (
  ErrInvalidParameter = merry.
    New("Invalid parameter").
    WithUserMessage("Invalid parameter").
    WithHTTPCode(http.StatusBadRequest)
)

Then in the controller I'd love to be able to write something like:

result, err := strconv.ParseBool(param)
if err != nil {
  // this should save the current stack and the err object, but maybe override the http code
  // and user/error message if present.
  return ErrInvalidParameter.Wrap(err)
}

Calling merry.Details(err) does not print an error's attached values, i.e. merry.New("x").WithValue("lololol", "asdasdasd").

Could it be made to print it? If it is just a matter of implementation, I would be happy to submit a pull request.

Hi! Could you please add a method extracting all the values from an error? Like map[string]interface{} or some iterator over them.

Most functions which take errors should allow for nil to be passed, and should return nil in these cases.