Repository navigation
Decorate misbehave if err==nil #40
Description
Activity
Come to think of it, I agree. This is not an intended way to use the library.
The issue is: this will potentially break some existing user code, which is a bad thing. At run time, which is worse.
I'm not sure at this point that the reasoning along the lines of "but there's nothing in godoc that promised to keep this behaviour" is good enough.
Need to think more about this.Formally it looks more like not a breaking change but an API clarification. But I do agree that it might break some code.
I would certainly object against solutions like "let's just introduce
DecorateV2" 😄. Personally I think that it isn't a big deal in changing something that wasn't specified as a public contract.No, there may be only one
Decorate.
I think a breaking change would require a major release, and we may have other things of that sort to bundle together - say, a neglected issue ofWrapnaming.@PeterIvanov is this issue resolved?
@Tochemey I'm afraid it is not. Do you have a comment on the subject matter, one way or another?
- added a commit that references this issue
on Apr 14, 2026
What happens?
errorx.Decoratereturns an error with the following properties:e.IsOfType(...)always returnsfalsee.Type()returnssynthetic.foreignI suggest that
errorx.Decorate(nil, "")should either return nil or panic.