Thanks Zik, not clear if I still need to publish v2.0.1 to retract
v2.0.0+incompatible given the comments in
https://play-with-go.dev/retract-module-versions_go116_en/
To retract v1.0.0 you will need to publish v1.0.1. But that means you will
> *also* need to retract version v1.0.1.
I wonder if
On Fri, Dec 31, 2021 at 3:04 AM Peter W wrote:
>
> It’s possible to let the caller or callee take the responsibility of graceful
> shutdown?
I don't see how to do that in a reasonable manner. Any Go code can
start a goroutine, including code in some external package that you
without even knowin
I seem to see some discussion about unloading lib that mentioned runtime
reflect, probably it’s regarding shared not c-shared.
It’s possible to let the caller or callee take the responsibility of
graceful shutdown?
Peter
On Tuesday, December 28, 2021 at 9:34:37 PM UTC+2 Ian Lance Taylor wrote
On Friday, 31 December 2021 at 08:10:49 UTC Henry wrote:
> The purpose of error wrapping is to give contextual information about the
> error. It is supposed to help you understand and locate the error. For
> instance, *"invalid filename"* is not particularly useful when compared
> to *"fail to
The purpose of error wrapping is to give contextual information about the
error. It is supposed to help you understand and locate the error. For
instance, *"invalid filename"* is not particularly useful when compared to
*"fail
to load customer data: invalid filename"*. Error wrapping is a stack
