pers, rather than flowery descriptive text
> written for the end user. If you need text for the end user, translate it
> at the point of intercepting the error and doing something with it.
>
> And of course, I believe Effective Go <https://go.dev/doc/effective_go> has
> a bit to
you again for your sharing.
2025년 2월 4일 화요일 오전 3시 2분 37초 UTC+9에 Mike Schinkel님이 작성:
On Feb 3, 2025, at 6:01 AM, Byungjun You wrote:
In Java, checked exceptions allow developers to define in advance which
exceptions a function can throw. However, it seems that Go does not have
such a feature. W
In Java, checked exceptions allow developers to define in advance which
exceptions a function can throw. However, it seems that Go does not have
such a feature. Would it be considered a best practice in Go to document
the possible errors that an API function can return? Additionally, what are
that's perfect! Pretty much what I was looking for. Let me test it and
> get back to you.
>
> I wonder where the blog author found that flag? It's not exposed in `go
> test`
>
> On Tuesday, January 14, 2025 at 5:27:07 AM UTC-8 Byungjun You wrote:
>
>> Have you
Have you try go test with -args -test.gocoverdir parameters?
> go test -cover ./... -args -test.gocoverdir="{a directory where coverage
reports should be generated}"
I found this blog post is very helpful when merging unit and integration
test coverage reports.
https://dustinspecker.com/posts/g
