[go-nuts] Error handling
I've been playing around with reducing error handling boilerplate using
standard language constructs.
I'm currently doing something that looks like this:
import (
"github.com/michaelmacinnis/handle"
)
func do(name string) (err error) {
check, handle := handle.Errorf(, "do(%s)", name); defer handle()
s, err := works(name); check(err)
// ...
}
Other than the named return value and check being a hidden return, are
there reasons I would want to avoid doing this? I assume others have tried
similar things but I haven't stumbled across any similar packages.
Before using it in production I would probably want a linter that checks to
make sure that the statement after handle.Error or handle.Errorf is defer
blah, where blah is the name given to the second value returned by those
functions and that all of this happens at the start of a function.
Michael.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/cbe53d07-4f99-49fa-a708-dcb85b1aff5bn%40googlegroups.com.
[go-nuts] Re: How to get VSCode to use different Go env vars for different directories in the same repo?
Try setting ""go.testEnvVars"" and "go.toolsEnvVars" On Sunday, 14 February 2021 at 4:42:06 am UTC+8 michael...@gmail.com wrote: > *(Sorry for posting what is mostly a VSCode question. I've asked it on > StackOverflow without getting any responses. Am reposting here in the hope > that some has already run into this problem and figured out how to deal > with it.)* > > I have a Go project that builds a WebAssembly (WASM) app and a backend > server for it. Both pieces build and run without errors. VSCode, however, > produces an annoying linter error in the WASM app. > > ``` > could not import syscall/js (no required module provides package > "syscall/js") > ``` > > The problem, as I currently understand it, is that VSCode doesn't infer > from the build tags that it should invoke `gopls` with `env GOOS=js > GOARCH=wasm` and that one solution is to set these tags as workspace Go > environment vars. > > The app design, however, relies on providing a common internal package to > both the wasm and the server code so that each side sees some struct > definitions that simplify the interface between them. To that end, the repo > is organized (simplified view) as follows: > > ``` > cmd > ├── internal > │ └── common > │ ├── common.go > │ └── common_test.go > ├── server > │ └── main.go > └── wasm > └── main.go > ``` > > How can I configure VSCode to use `env GOOS=js GOARCH=wasm` when linting > the wasm directory and not for other directories? > > > > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/56b1c978-8dc9-4b2e-8b2d-f7558f701e0bn%40googlegroups.com.
[go-nuts] How to get VSCode to use different Go env vars for different directories in the same repo?
*(Sorry for posting what is mostly a VSCode question. I've asked it on StackOverflow without getting any responses. Am reposting here in the hope that some has already run into this problem and figured out how to deal with it.)* I have a Go project that builds a WebAssembly (WASM) app and a backend server for it. Both pieces build and run without errors. VSCode, however, produces an annoying linter error in the WASM app. ``` could not import syscall/js (no required module provides package "syscall/js") ``` The problem, as I currently understand it, is that VSCode doesn't infer from the build tags that it should invoke `gopls` with `env GOOS=js GOARCH=wasm` and that one solution is to set these tags as workspace Go environment vars. The app design, however, relies on providing a common internal package to both the wasm and the server code so that each side sees some struct definitions that simplify the interface between them. To that end, the repo is organized (simplified view) as follows: ``` cmd ├── internal │ └── common │ ├── common.go │ └── common_test.go ├── server │ └── main.go └── wasm └── main.go ``` How can I configure VSCode to use `env GOOS=js GOARCH=wasm` when linting the wasm directory and not for other directories? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c6f30190-8bdf-4a75-b787-7501c711785bn%40googlegroups.com.
Re: [go-nuts] about -buildmode c-shared
On Sat, Feb 13, 2021 at 1:53 AM Frédéric De Jaeger wrote: > > On Tuesday, February 9, 2021 at 2:46:33 AM UTC+1 Ian Lance Taylor wrote: >> >> >> >> Thanks, you may be correct: it may be possible to hide all symbols >> other than the ones that are intended to be exported to the C program. >> If it is possible to do that reliably in all cases, then the effect >> should be that if you link against multiple shared libraries, each >> will have an independent Go runtime. The program will wind up with >> different Go heaps and different garbage collectors competing with >> each other. The result will be inefficient, sometimes alarmingly so, >> but I don't immediately see any reason why it wouldn't work. >> > No bad surprise expected from other kind of uniqu per process resources ? > (signal? ...) > > I suppose you mean other kind of inefficiency than the basic ram usage ? > I've observed that when I run several CPU intensive go apps on the same host, > the cumulative GC pause (Memstats.PauseTotalNs) raises dramatically (not > linear in the number of go process running). But in more gentle scenario, > where the go plugin rarely runs, do we hit those inefficiencies ? Probably not. I would still be concerned about surprising behavior. > At the moment, go can't be used reliably as a tool to write C plugin for a > generic C host. Because of the runtime constraints, and the unloading issue. Yes. > I was naively assuming that the unloading issue is easy to tackle when the > runtime is not shared between .so. Is it true ? No. The current Go runtime has no ability to shut down all goroutines. If any goroutines are left running, and the plugin is unloaded, the program will crash. > I can see a difficulty when there are running go routines doing cgo > invocations (and we can probably fail/abort/crash in this case) . Apart from > that, I have the feeling this should be easy to cleanup all the runtime > ressources (memory, threads). I suppose this kind of cleanup logic was never > written because exit(0) does the same job. Yes, goroutines currently calling into C code are a particular problem, but they are not the only problem. > IMHO, being able to write generic C plugin in go, would be a good selling > feature (I would appreciate it as much as all the people here > https://github.com/golang/go/issues/11100). > So, suppose we implement that feature by hiding/unsharing the runtime > (assuming it works and we fill in the missing pieces) > The question is how bad would be that solution compared to the absence of > that feature ? > > Are there really some business usage of the current existing feature ? > (people really loading several `c-shared` go .so and expecting to share the > runtime) > What about yet another build mode like `c-shared-private-runtime` ? > unloading would be only implemented with this build mode. I tend to agree that if people want to use Go code as plugins to a C program, they would expect those Go plugins to operate independently. But I think that many people would be disappointed by the effects on resource usage, which they would have no way to mitigate. So we would have a feature that would make people unhappy in practice. > A last technical question, do you link the shared object with the ld flag `- > z nodelete` (which turn dlclose into no op). As far as I know we do not. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUAE%3DU_x3Ry-OaXPwkKLVeAuQDbMq9YPUQcUkTXpH-MoA%40mail.gmail.com.
Re: [go-nuts] about -buildmode c-shared
On Tuesday, February 9, 2021 at 2:46:33 AM UTC+1 Ian Lance Taylor wrote: > > > Thanks, you may be correct: it may be possible to hide all symbols > other than the ones that are intended to be exported to the C program. > If it is possible to do that reliably in all cases, then the effect > should be that if you link against multiple shared libraries, each > will have an independent Go runtime. The program will wind up with > different Go heaps and different garbage collectors competing with > each other. The result will be inefficient, sometimes alarmingly so, > but I don't immediately see any reason why it wouldn't work. > > No bad surprise expected from other kind of uniqu per process resources ? (signal? ...) I suppose you mean other kind of inefficiency than the basic ram usage ? I've observed that when I run several CPU intensive go apps on the same host, the cumulative GC pause (Memstats.PauseTotalNs) raises dramatically (not linear in the number of go process running). But in more gentle scenario, where the go plugin rarely runs, do we hit those inefficiencies ? At the moment, go can't be used reliably as a tool to write C plugin for a generic C host. Because of the runtime constraints, and the unloading issue. I was naively assuming that the unloading issue is easy to tackle when the runtime is not shared between .so. Is it true ? I can see a difficulty when there are running go routines doing cgo invocations (and we can probably fail/abort/crash in this case) . Apart from that, I have the feeling this should be easy to cleanup all the runtime ressources (memory, threads). I suppose this kind of cleanup logic was never written because exit(0) does the same job. IMHO, being able to write generic C plugin in go, would be a good selling feature (I would appreciate it as much as all the people here https://github.com/golang/go/issues/11100). So, suppose we implement that feature by hiding/unsharing the runtime (assuming it works and we fill in the missing pieces) The question is how bad would be that solution compared to the absence of that feature ? Are there really some business usage of the current existing feature ? (people really loading several `c-shared` go .so and expecting to share the runtime) What about yet another build mode like `c-shared-private-runtime` ? unloading would be only implemented with this build mode. A last technical question, do you link the shared object with the ld flag `- z nodelete*` *(which turn dlclose into no op). > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f1332fdc-67c4-492e-9810-02cfc95eda7bn%40googlegroups.com.
