Unwrap `joinErr` in `gin.Error()`

[slhmy]

In go errors pkg can create a joinErr by errors.Join(), which can be Unwrap() into []error. joinErr also format it's print into \n separated string, which is similar with gin.errorMsgs.String() but can cause confuse, when they are used together:

Error #01 gin error
Error #02 service error
store error
Error #03 other error

In this case service error & store error is combined with a joinErr. I think it will be better if we can see:

Error #01 gin error
Error #02 service error
Error #03 store error
Error #04 other error

Even though we can unwrap joinErr before we use gin.Error(), it will be better if gin.Error() do the unwrap for us as a internal logic.

[arshukla98]

Hi, I would like to work on this issue. Can anyone assign this issue to me?

[r0ld3x]

but doesn't it break some logs like

suppose I want to log a multi line text. For example:

this is a first text line
this is a second line
blabla bla

so if we do as you are proposing it will show

Error #01 this is a first text line
Error #02 this is a second line
Error #03 blabla bla

I think as a dev I would get confused whether it is same line or running on a loop and logging it

[slhmy]

but doesn't it break some logs like

suppose I want to log a multi line text. For example:

this is a first text line
this is a second line
blabla bla

so if we do as you are proposing it will show

Error #01 this is a first text line
Error #02 this is a second line
Error #03 blabla bla

I think as a dev I would get confused whether it is same line or running on a loop and logging it

No, it won't. If you see the code in errors/join.go:

func (e *joinError) Unwrap() []error {
	return e.errs
}

Only split the errors when error has Unwrap() []error implementation will be fine.

For multi line text in a single error, it won't be seprated.

[r0ld3x]

ok good catch then