Improve error logs

[applejag]

Is your feature request related to a problem? Please describe.
The error logs are very verbose.

Some parts of it, like the part that's showing which converter function we're talking about, I find is excessively verbose.

Then when there's something wrong with a field you get an output like this:

| goverter-test/pkg/sample.Source
|
|      | time.Time
|      |
source.CreatedAt.???
target.CreatedAt.wall
|      |         |
|      |         | uint64
|      |
|      | time.Time
|
| goverter-test/pkg/sample.Target

^it took me quite long before I understood that the pipe characters are arrows pointing to the fields. For a long time I thought it was a weird tree, but for some reason some parts were not indented.

Then I find it excessive to show absolute paths. I don't think you'd lose a bunch of info from changing that to relative paths.

The output could also benefit a lot from a splash of colors :)

Describe the solution you'd like
Instead of showing func (goverter-test/pkg/sample.Converter).ConvertFoo(source goverter-test/pkg/sample.Source, timeFormat string) goverter-test/pkg/sample.Target, I suggest just showing a verbatim output of the input code instead: ConvertFoo(source Source, timeFormat string) Target. I believe getting access to the AST tokens should be possible, right?

Also using some box-drawing characters would be nice: ╭╰─┴┬│

I've made a mockup for inspiration, where I tried to mimic the color theme used in the docs.

Before

After

Source code

�[41m Error while creating converter method: �[0m

�[90m   ╭── �[90;3mfile: ./sample.go�[0m
�[90m … │�[0m
�[90m 7 │�[0m �[90m// goverter:converter�[0m
�[90m 8 │�[0m �[91mtype�[0m �[35mConverter�[0m �[91minterface�[0m {
�[90m … │�[0m
�[90m13 │�[0m     �[90m// goverter:map Name | strings.ToUpper�[0m
�[90m14 │�[0m     �[90m// goverter:context timeFormat�[0m
�[90m15 │�[0m     �[0mConvertFoo�[0m(�[33msource�[0m �[35mSource�[0m, �[33mtimeFormat�[0m �[91mstring�[0m) �[35mTarget�[0m
�[90m … │�[0m
�[90m18 │�[0m }

        �[48;5;88m[source]�[0m  �[90mgoverter-test/pkg/�[0m�[35msample�[0m.�[35mSource�[0m
        �[48;5;20m[context]�[0m �[91mstring�[0m
        �[48;5;22m[target]�[0m  �[90mgoverter-test/pkg/�[0m�[35msample�[0m.�[35mTarget�[0m

�[38;5;88m   ╭──�[0m �[90mgoverter-test/pkg/�[0m�[35msample�[0m.�[35mSource�[0m
�[38;5;88m   │       ╭──�[0m �[35mtime�[0m.�[35mTime�[0m
�[38;5;88m───┴── ────┴────�[0m
�[48;5;88msource�[0m.CreatedAt.�[41m???�[0m
�[48;5;22mtarget�[0m.CreatedAt.wall
�[38;5;22m───┬── ────┬──── ──┬─�[0m
�[38;5;22m   │       │       ╰──�[0m �[91muint64�[0m
�[38;5;22m   │       ╰──�[0m �[35mtime�[0m.�[35mTime�[0m
�[38;5;22m   ╰──�[0m �[90mgoverter-test/pkg/�[0m�[35msample�[0m.�[35mTarget�[0m

�[31mCannot set value for unexported field "wall".�[0m

See �[36mhttps://goverter.jmattheis.de/guide/unexported-field�[0m

Sample code block of how it would look in GitHub when uncolored

 Error while creating converter method:

   ╭── file: ./sample.go
 … │
 7 │ // goverter:converter
 8 │ type Converter interface {
 … │
13 │     // goverter:map Name | strings.ToUpper
14 │     // goverter:context timeFormat
15 │     ConvertFoo(source Source, timeFormat string) Target
 … │
18 │ }

        [source]  goverter-test/pkg/sample.Source
        [context] string
        [target]  goverter-test/pkg/sample.Target

   ╭── goverter-test/pkg/sample.Source
   │       ╭── time.Time
───┴── ────┴────
source.CreatedAt.???
target.CreatedAt.wall
───┬── ────┬──── ──┬─
   │       │       ╰── uint64
   │       ╰── time.Time
   ╰── goverter-test/pkg/sample.Target

Cannot set value for unexported field "wall".

See https://goverter.jmattheis.de/guide/unexported-field

(If you want I can create more mockups for other error types. I'd probably be interested in trying to help contribute this too)

The colored output part should respect your terminal's color support, which should be easy enough by using a library like https://github.com/charmbracelet/lipgloss. Also there should be a flag like --color=always or --force-colors to enable colored output even when doing things like piping the output or when running inside GitHub Actions.

Describe alternatives you've considered
nothing comes to mind

[jmattheis]

I find it excessive to show absolute paths. I don't think you'd lose a bunch of info from changing that to relative path

I like the absolute paths, because these tools are mostly executed by go generate ./..., and then the command could be in a sub package and then the relative path could be wrong.

I suggest just showing a verbatim output of the input code instead

I'd be okay with this, tho maybe we don't use the verbatim but instead generate it to always have it in one line, so we could do something like this, instead of the [source]

But having the full types is also useful, do you have an idea that includes both?

Also using some box-drawing characters would be nice

Are they supported everywhere? The Rust compiler doesn't use these, and instead uses only the base ascii charset. They do look better, but I'd take compatibility over nice looking.

The colored output part should respect your terminal's color support

I'm okay with color support, tho it should not increase the complexity in the code to much, I'd rather have simpler code instead of color support, as this is only nice to have imo.

If possible, I'd rather not use a library for this, if it doubles the dependencies it currently has, having some ansi sequences as constants should be good enough.

And, I'd like less colors as they are currently, it looks kinda overloaded with the different background and foreground colors.

[applejag]

I find it excessive to show absolute paths. I don't think you'd lose a bunch of info from changing that to relative path

I like the absolute paths, because these tools are mostly executed by go generate ./..., and then the command could be in a sub package and then the relative path could be wrong.

Fare. And doing some logic to get the relative path from the go.mod could be "too magic" and unclear to the user. Abs paths it is then.

On the other hand, replacing a $HOME/ prefix with ~/ could be a nice middleground to not having to post your username everywhere while also shortening the path a little.

I suggest just showing a verbatim output of the input code instead

I'd be okay with this, tho maybe we don't use the verbatim but instead generate it to always have it in one line, so we could do something like this, instead of the [source]

But having the full types is also useful, do you have an idea that includes both?

The box drawing on the lines below do show the full types on the related types. Though idk if for example knowing all the types is always essential. Like not knowing the full context type here in this error message in particular doesn't matter.

Also adding box drawing on the source code line could become messy due to wrapping as the code will likely be longer than your terminal width. Like if you add in an error response, some package names, and perhaps some longer type and function names then the width will go wild.

In comparison the box drawing part of the section below the source code snippet won't necessarily be that wide.

Hmm maybe could be represented in a list below the function, line:

15 |     ConvertFoo(mySrc Source, myCtx Context) Target
 … |       › source:  goverter-test/pkg/sample.Source
 … |       › context: goverter-test/pkg/sample.Context
 … |       › target:  goverter-test/pkg/sample.Source

Also using some box-drawing characters would be nice

Are they supported everywhere? The Rust compiler doesn't use these, and instead uses only the base ascii charset. They do look better, but I'd take compatibility over nice looking.

Utf8 and unicode support nowadays could be assumed to be a given. However, the font rendering is a different story, as some monospace fonts do not consider them.

This is a minor issue on mobile where it looks a little off like this:

Chrome	Firefox	GitHub app

Also the characters I used are the curvy box drawing characters which may be less supported than the super old square looking characters ┌┐┴┬

In what regard are you worried about the compatibility? Like tools breaking or terminals misrendering?

The colored output part should respect your terminal's color support

I'm okay with color support, tho it should not increase the complexity in the code to much, I'd rather have simpler code instead of color support, as this is only nice to have imo.

If possible, I'd rather not use a library for this, if it doubles the dependencies it currently has, having some ansi sequences as constants should be good enough.

Myeah though this is usually where the libs come in to help with the plumbing of detecting color support and how to translate the colors on windows terminals.

And, I'd like less colors as they are currently, it looks kinda overloaded with the different background and foreground colors.

Gotcha

[applejag]

Wdyt about this?

Source

�[31mError while creating converter method:�[0m

�[90m   ┌── �[90;3mfile: ~/code/gh/goverter-test/pkg/sample/sample.go�[0m
�[90m … │�[0m
�[90m 7 │�[0m �[90m// goverter:converter�[0m
�[90m 8 │�[0m �[91mtype�[0m �[35mConverter�[0m �[91minterface�[0m {
�[90m … │�[0m
�[90m13 │�[0m     �[90m// goverter:map Name | strings.ToUpper�[0m
�[90m14 │�[0m     �[90m// goverter:context timeFormat�[0m
�[90m15 │�[0m     �[0mConvertFoo�[0m(�[33msource�[0m �[35mSource�[0m, �[33mtimeFormat�[0m �[91mstring�[0m) �[35mTarget�[0m
�[90m … │�[0m     �[90m├ source:�[0m  �[90mgoverter-test/pkg/�[0m�[35msample�[0m.�[35mSource�[0m
�[90m … │�[0m     �[90m├ context:�[0m �[91mstring�[0m
�[90m … │�[0m     �[90m└ target:�[0m  �[90mgoverter-test/pkg/�[0m�[35msample�[0m.�[35mTarget�[0m
�[90m … │�[0m
�[90m18 │�[0m }

�[38;5;88m   ┌──�[0m �[90mgoverter-test/pkg/�[0m�[35msample�[0m.�[35mSource�[0m
�[38;5;88m   │       ┌──�[0m �[35mtime�[0m.�[35mTime�[0m
�[38;5;88m───┴── ────┴────�[0m
�[38;5;88msource�[0m.CreatedAt.�[41m???�[0m
�[38;5;22mtarget�[0m.CreatedAt.wall
�[38;5;22m───┬── ────┬──── ──┬─�[0m
�[38;5;22m   │       │       └──�[0m �[91muint64�[0m
�[38;5;22m   │       └──�[0m �[35mtime�[0m.�[35mTime�[0m
�[38;5;22m   └──�[0m �[90mgoverter-test/pkg/�[0m�[35msample�[0m.�[35mTarget�[0m

�[31mCannot set value for unexported field "wall".�[0m

See �[36mhttps://goverter.jmattheis.de/guide/unexported-field�[0m

Sample code block of how it would look in GitHub when uncolored

Error while creating converter method:

   ┌── file: ~/code/gh/goverter-test/pkg/sample/sample.go
 … │
 7 │ // goverter:converter
 8 │ type Converter interface {
 … │
13 │     // goverter:map Name | strings.ToUpper
14 │     // goverter:context timeFormat
15 │     ConvertFoo(source Source, timeFormat string) Target
 … │     ├ source:  goverter-test/pkg/sample.Source
 … │     ├ context: string
 … │     └ target:  goverter-test/pkg/sample.Target
 … │
18 │ }

   ┌── goverter-test/pkg/sample.Source
   │       ┌── time.Time
───┴── ────┴────
source.CreatedAt.???
target.CreatedAt.wall
───┬── ────┬──── ──┬─
   │       │       └── uint64
   │       └── time.Time
   └── goverter-test/pkg/sample.Target

Cannot set value for unexported field "wall".

See https://goverter.jmattheis.de/guide/unexported-field

Some testing:

GNOME terminal

Konsole

Ghostty

GitHub actions

[jmattheis]

Wdyt about this?

I like the list! it now looks much less out of place than the [source] thing before.

On the other hand, replacing a $HOME/ prefix with ~/ could be a nice middleground to not having to post your username everywhere while also shortening the path a little.

Maybe yes, but I think most tools that output absolute paths doesn't do this.

In what regard are you worried about the compatibility? Like tools breaking or terminals misrendering?

Yeah, mostly misrendering. Do the square boxes have better support on mobile?

Maybe we can format this differently to remove the need for special chars, e.g.

target <- goverter-test/pkg/sample.Target
      .CreatedAt <- time.Time
                .wall <- uint64

this would make it more compact but likely have more columns.

Myeah though this is usually where the libs come in to help with the plumbing of detecting color support and how to translate the colors on windows terminals.

Okay, true. Then it's probably okay to have a lib for that. To get free support for different platforms.

[applejag]

In what regard are you worried about the compatibility? Like tools breaking or terminals misrendering?

Yeah, mostly misrendering. Do the square boxes have better support on mobile?

The square ones did not have a difference. It seems like the horizontal and vertical lines are the issue. They're from the same character set so it's kind of annoying that only some parts render correctly when the font is configured as a monospace font. Oh well.

Maybe we can format this differently to remove the need for special chars, e.g.

target <- goverter-test/pkg/sample.Target
      .CreatedAt <- time.Time
                .wall <- uint64

this would make it more compact but likely have more columns.

That's a great idea! I wonder how noisy that gets though when you have source and target next to each other.

I guess it'd be something like this:

source <- goverter-test/pkg/sample.Source
      .CreatedAt <- time.Time
                .???

target <- goverter-test/pkg/sample.Target
      .CreatedAt <- time.Time
                .wall <- uint64

It could be nice to have a line like this above it to better show what's going on:

source.CreatedAt.??? = target.CreatedAt.wall

[applejag]

Thoughts?

[applejag]

I also double-checked, and it's only the horizontal line ─ that gets messed up on mobile. The vertical line │ and the intersections work just fine (albeit not connected due to a higher line height)

[jmattheis]

Maybe like this,

source <- goverter-test/pkg/sample.Source
      .CreatedAt <- time.Time
                .wall <- uint64
                .???
      .CreatedAt <- time.Time
target <- goverter-test/pkg/sample.Target

But this seems difficult to understand. Hmm I think I like the your improvement on the original structure better, as the path is more clear. Then maybe we have to life with the wrong rendering or use simpler characters.

target.CreatedAt.wall
--+--- ---+----- ---- uint
  |       |      
  |       +- time.Time
  +- goverter-test/pkg/sample.Target

Thoughts?

I feel like having it separated like this makes it more difficult to understand both paths, like that ??? and .wall are on the same level.

---

Another idea would be to split it into steps

mapping steps:

source <- goverter-test/pkg/sample.Source
target <- goverter-test/pkg/sample.Target

source.CreatedAt <- time.Time
target.CreatedAt <- time.Time

source.CreatedAt.???
target.CreatedAt.wall <- uint64

[applejag]

source <- goverter-test/pkg/sample.Source
      .CreatedAt <- time.Time
                .wall <- uint64
                .???
      .CreatedAt <- time.Time
target <- goverter-test/pkg/sample.Target

But this seems difficult to understand.

Agreed. It's closer to the current goverter error format with the issue of it not really being "glance'able"

I feel like having it separated like this makes it more difficult to understand both paths, like that ??? and .wall are on the same level.

Good point. Feels like the .wall and .??? must be visually near each other.

---

For reference, what an ASCII variant would look like:

Given it's also only the horizontal lines that are buggy on mobile then we could do it completely without that character specifically:

I was also playing around with your "steps" idea and mocked up this:

^I reversed it to have the most significant info first. Also I skipped the explanation of source and target as those are explained already below the function next to the context: definition.

That has such a "clean design" that the code block above it looks too noisy in comparison 😅

[jmattheis]

Maybe we could make the source reference more sleek like this?

Error while creating converter method:
    ~/src/jmattheis/goverter/sample.go
    13 │ // goverter:map Name | strings.ToUpper
    14 │ // goverter:context timeFormat
    15 │ ConvertFoo(source Source, timeFormat string) Target
         | source:  goverter-test/pkg/sample.Source
         | context: goverter-test/pkg/sample.Context
         | target:  goverter-test/pkg/sample.Source

I do kinda like the step design for this case where the path is small. I don't think it works well for unbalanced paths, e.g. https://github.com/jmattheis/goverter/blob/main/scenario/map_nested_missing_field.yml or https://github.com/jmattheis/goverter/blob/main/scenario/struct_method_fail_nested_mismatch_custom.yml

Given it's also only the horizontal lines that are buggy on mobile then we could do it completely without that character specifically:

Then it's not much difference between the original implementation no?

I'm not really sure what I like best, I don't dislike the ascii only thing, but with the special box chars it does look more sleek. Do you think there is a difference in understanding what it means between the two solutions? Given that the ascii case likely doesn't has rendering problems I'd prefer it.

[applejag]

Maybe we could make the source reference more sleek like this?

Error while creating converter method:
    ~/src/jmattheis/goverter/sample.go
    13 │ // goverter:map Name | strings.ToUpper
    14 │ // goverter:context timeFormat
    15 │ ConvertFoo(source Source, timeFormat string) Target
         | source:  goverter-test/pkg/sample.Source
         | context: goverter-test/pkg/sample.Context
         | target:  goverter-test/pkg/sample.Source

Ah yes! I really like that!

I wonder if the source, context, & target mentions should then be in its own "Where" clause if we consider the steps/"Caused by" alternative:

Error while creating converter method:
  ~/src/jmattheis/goverter/sample.go
  13 │ // goverter:map Name | strings.ToUpper
  14 │ // goverter:context timeFormat
  15 │ ConvertFoo(source Source, timeFormat string) Target

Where:
  Source  is goverter-test/pkg/sample.Source
  Context is goverter-test/pkg/sample.Context
  Target  is goverter-test/pkg/sample.Source

Error: Cannot set value for unexported field "wall".

Caused by:
  source.CreatedAt.???  is missing
  target.CreatedAt.wall is uint64

Where:
  source.CreatedAt is time.Time
  target.CreatedAt is time.Time

Or hmm that got a bit cluttered. So maybe best to merge them. Don't know how to properly highlight contexts, but perhaps best to use their argument names. Something like:

Error while creating converter method:
  ~/src/jmattheis/goverter/sample.go
  13 │ // goverter:map Name | strings.ToUpper
  14 │ // goverter:context timeFormat
  15 │ ConvertFoo(source Source, timeFormat string) Target

Error: Cannot set value for unexported field "wall".

Caused by:
  source.CreatedAt.???  is missing
  target.CreatedAt.wall is uint64

Where:
  source.CreatedAt is time.Time
  source           is goverter-test/pkg/sample.Source
  target.CreatedAt is time.Time
  target           is goverter-test/pkg/sample.Source
  timeFormat       is goverter-test/pkg/sample.Context

I don't think it works well for unbalanced paths, e.g. https://github.com/jmattheis/goverter/blob/main/scenario/map_nested_missing_field.yml or https://github.com/jmattheis/goverter/blob/main/scenario/struct_method_fail_nested_mismatch_custom.yml

The way I see it is that the "Caused by" contains the most relevant info, and then the "Where" contains additional context. So for your two examples there I think they could have a structure like:

Error: Cannot access 'Oops' on int.

Caused by:
  source.Nested.Name.Oops is missing
  target.Name             is string

Where:
  source.Nested.Name is int
  source.Nested      is github.com/jmattheis/goverter/execution.Nested
  source             is github.com/jmattheis/goverter/execution.Input
  target             is github.com/jmattheis/goverter/execution.Output

^ https://github.com/jmattheis/goverter/blob/main/scenario/map_nested_missing_field.yml

Error: Method source type mismatches with conversion source: string != *time.Time

Caused by:
  source.Nested.Inner.Inner2.Name is func() time.Time
  target.Name                     is *string

Where:
  source.Nested.Inner.Inner2 is *github.com/jmattheis/goverter/execution.InputNestedNestedNested
  source.Nested.Inner        is github.com/jmattheis/goverter/execution.InputNestedNested
  source.Nested              is *github.com/jmattheis/goverter/execution.InputNested
  source                     is github.com/jmattheis/goverter/execution.Input
  target                     is github.com/jmattheis/goverter/execution.Output

Error using method:
  func github.com/jmattheis/goverter/execution.MapName(string) string
      [source] string
      [target] string

^ https://github.com/jmattheis/goverter/blob/main/scenario/struct_method_fail_nested_mismatch_custom.yml

I think having a list like that also wraps nicely on narrow screens/terminals as it's quite easy to follow what maps to what. The additional "table-like alignment" is to hopefully make it more readable.

On that last one I'm wondering if the chain should continue, where the execution.MapName has its source printed and it has its own "Caused by" and "Where" sections? Kind of like how nested exceptions in Java or nested panics in Go are printed.

Given it's also only the horizontal lines that are buggy on mobile then we could do it completely without that character specifically:

Then it's not much difference between the original implementation no?

Lol you're completely right! Though the box drawing symbols do help make it slightly more legible. It would certainly be one of the easier error format restructuring to implement 😅

Personally I'm actually growing quite fond of this "Caused by"/"Where" alternative. It give me "less is more" kind of vibes.

[jmattheis]

I wonder if the source, context, & target mentions should then be in its own "Where" clause if we consider the steps/"Caused by" alternative:

Or hmm that got a bit cluttered. So maybe best to merge them. Don't know how to properly highlight contexts, but perhaps best to use their argument names. Something like:

IMO this should stay as close as possible to the signature, as it's directly related to it and describes what category the args belong to

---

"Caused by" is also misleading in some of the errors. The last one it's actually caused because the method signature

Error using method:
  func github.com/jmattheis/goverter/execution.MapName(string) string
                                                       ^^^^^^

mismatches with source.Nested.Inner.Inner2.Name()

---

Another thing that get lost with the "caused by" format is what extend methods could be added. E.g.

| goverter-test/pkg/sample.Source
|
|      | time.Time
|      |
source.CreatedAt.???
target.CreatedAt.wall
|      |         |
|      |         | uint64
|      |
|      | time.Time
|
| goverter-test/pkg/sample.Target

You see that createdAt time.Time on source and target are on the same level, so you could create a extend:method to add a custom method for this.

This is not a must have, as the caused by is clearer, but maybe we find another way to display this?

[applejag]

This is not a must have, as the caused by is clearer, but maybe we find another way to display this?

I'm actually running low on energy for this bikeshedding. It has been an enjoyable brainstorm but I'm kind of drained now.

If I get this right the latest proposal we're at is something like this:

Error while creating converter method:
  ~/src/jmattheis/goverter/sample.go
  13 │ // goverter:map Name | strings.ToUpper
  14 │ // goverter:context timeFormat
  15 │ ConvertFoo(source Source, timeFormat string) Target
       | source:  goverter-test/pkg/sample.Source
       | context: goverter-test/pkg/sample.Context
       | target:  goverter-test/pkg/sample.Source

Error: Cannot access 'Oops' on int.

Found when converting:
  source.Nested.Inner.Inner2.Name is func() time.Time
  target.Name                     is *string

Where:
  source.Nested.Inner.Inner2 is *github.com/jmattheis/goverter/execution.InputNestedNestedNested
  source.Nested.Inner        is github.com/jmattheis/goverter/execution.InputNestedNested
  source.Nested              is *github.com/jmattheis/goverter/execution.InputNested

Error using method:
  func github.com/jmattheis/goverter/execution.MapName(string) string
  | source: string
  | target: string

[jmattheis]

Yeah, thanks for your time (:. I'm generally okay with this being implemented. We can probably decide on an order when all the errors in the scenarios are migrated, so we see what fits best. I think I'd prefer these specific errors in this order.

This makes the error more clear, as it's directly at the start.

Error: Method source type mismatches with conversion source: string != *time.Time

Using method:
    func github.com/jmattheis/goverter/execution.MapName(string) string
        [source] string
        [target] string

While creating conversion method:
    ~/src/jmattheis/goverter/sample.go
    13 │ // goverter:map Name | strings.ToUpper
    14 │ // goverter:context timeFormat
    15 │ ConvertFoo(source Source, timeFormat string) Target

At path:
    source.Nested.Inner.Inner2.Name is func() time.Time
    target.Name                     is *string

Where:
    source.Nested.Inner.Inner2 is *github.com/jmattheis/goverter/execution.InputNestedNestedNested
    source.Nested.Inner        is github.com/jmattheis/goverter/execution.InputNestedNested
    source.Nested              is *github.com/jmattheis/goverter/execution.InputNested

Cannot set value for unexported field "wall".

See https://goverter.jmattheis.de/guide/unexported-field

While creating conversion method:
    ~/src/jmattheis/goverter/sample.go
    13 │ // goverter:map Name | strings.ToUpper
    14 │ // goverter:context timeFormat
    15 │ ConvertFoo(source Source, timeFormat string) Target
         | source:  goverter-test/pkg/sample.Source
         | context: goverter-test/pkg/sample.Context
         | target:  goverter-test/pkg/sample.Source

At path:
    source.CreatedAt.???  is missing
    target.CreatedAt.wall is uint64

Where:
    source.CreatedAt is time.Time
    source.CreatedAt is time.Time
    source.Nested              is *github.com/jmattheis/goverter/execution.InputNested