3 ms·

The whole point of using Go is to explicitly handle errors as they happen. All of these steps can fail, but it’s not clear how they fail and if the next steps s

The whole point of using Go is to explicitly handle errors as they happen. All of these steps can fail, but it’s not clear how they fail and if the next steps should proceed or be skipped on previous failures. This is harder to reason about, debug, and write than grep and bash.

mst 3y ago
It defaults to not running the rest if a step fails, and the error result is accessible via usual mechanisms. _, err := script.Foo(...).Bar(...).Stdout(); if err != nil { log.Fatal(err) } is sufficient for a quick scripting hack designed to be run interactively. I don't see it as a lot different to bash scripts with -e and pipefail set, which is generally preferable anyway. Plenty of go code does if err != nil { return nil, err; } for each step and there are plenty of cases where you only care -if- it failed plus a description of some sort of the failure - if you want to proceed on some errors you'd split the pipe up so that it pauses at moments where you can check that and compensate accordingly. (and under -e plus pipefail, "error reported to stdout followed by aborting" is pretty much what you get in bash as well, so I'm unconvinced it's actually going to be harder to debug)
simonw 3y ago
I believe error handling looks like this: package main import ( "github.com/bitfield/script" ) func main() { _, err := script.Stdin().Column(1).Freq().First(10).Stdout() if err != nil { log.Fatal(err) } } Errors are "remembered" by the pipeline and can be processed when you get to a sink method.
coldtea 3y ago
>The whole point of using Go is to explicitly handle errors as they happen That's hardly the whole point of using Go. The friendlier syntax (and in this case DSL) is an ever bigger point. In any case, you can trivially get at the error at the point it occured: n, err := script.File("test.txt").Match("Error").CountLines()
_0w8t 3y ago
From a technical point of view nothing prevents the scripting package to be just as informative with errors as bash and have a helper to log and clear the error. If it is not already the case, I call it a bug.

mst 3y ago

It defaults to not running the rest if a step fails, and the error result is accessible via usual mechanisms. _, err := script.Foo(...).Bar(...).Stdout(); if err != nil { log.Fatal(err) } is sufficient for a quick scripting hack designed to be run interactively. I don't see it as a lot different to bash scripts with -e and pipefail set, which is generally preferable anyway. Plenty of go code does if err != nil { return nil, err; } for each step and there are plenty of cases where you only care -if- it failed plus a description of some sort of the failure - if you want to proceed on some errors you'd split the pipe up so that it pauses at moments where you can check that and compensate accordingly. (and under -e plus pipefail, "error reported to stdout followed by aborting" is pretty much what you get in bash as well, so I'm unconvinced it's actually going to be harder to debug)

simonw 3y ago

I believe error handling looks like this: package main import ( "github.com/bitfield/script" ) func main() { _, err := script.Stdin().Column(1).Freq().First(10).Stdout() if err != nil { log.Fatal(err) } } Errors are "remembered" by the pipeline and can be processed when you get to a sink method.

coldtea 3y ago

>The whole point of using Go is to explicitly handle errors as they happen That's hardly the whole point of using Go. The friendlier syntax (and in this case DSL) is an ever bigger point. In any case, you can trivially get at the error at the point it occured: n, err := script.File("test.txt").Match("Error").CountLines()

_0w8t 3y ago

From a technical point of view nothing prevents the scripting package to be just as informative with errors as bash and have a helper to log and clear the error. If it is not already the case, I call it a bug.