On Sun, Dec 26, 2021 at 3:45 PM Peter W wrote:
>
> I am trying to load, call and unload multiple go libs which are built with
> -buildmode c-shared in a c problem, it’s doable on windows, Linux and macOS ?
> Also I see -buildmode shared removal was rejected, what about -buildmode
> archive?
Yo
Hi guys,
I am trying to load, call and unload multiple go libs which are built with
-buildmode
c-shared in a c problem, it’s doable on windows, Linux and macOS ? Also I
see -buildmode shared removal was rejected, what about -buildmode archive?
Happy holidays!
On Monday, February 15, 2021 at 1
ISTM the alternative is return a semantically-meaningful error at the
current level of execution.
e.g. if you're trying to open a config file and it fails, you return
"Unable to open config file"; or better, include the text version of the
underlying error: e.g. "Unable to open config file: 'fo
Yes, of course I'm quite familiar with Go 1.13's error capabilities.
github.com/pkg/errors is still useful when one wants to attach stack traces
to errors.
But this leaves my question open: What are alternatives to wrapping
errors? (Other than passing around errors with no semantic meaning, a
