Eventually you do something like this:
package main import ( "log" "io/ioutil" "os" ) func main() { handle := func (v interface{}, err error) interface{} { if err != nil { log.Fatal(err) } return v } hex := handle(ioutil.ReadAll(os.Stdin)) data := handle(parseHexdump(string(hex))) os.Stdout.Write(data) }
Which I've seen in some other examples as:
package main import ( "log" "io/ioutil" "os" ) func main() { checkError := func (err error) { if err != nil { log.Fatal(err) } } hex, err := ioutil.ReadAll(os.Stdin) checkError(err) data, err = parseHexdump(string(hex)) checkError(err) os.Stdout.Write(data) }
To be honest, while this proposed solution works, it still looks like we only saving a few keystrokes. It's good but not great.
That doesn't work for returning errors, though. What if I wanted to return a wrapped version of the error?
Fair enough, but in that case, the wrapping is implicit and it looks like a twisted version of a try/catch block, something that spreads confusion.
I would prefer something like this:
func main() { check { hex := ioutil.ReadAll(os.Stdin) data := parseHexdump(string(hex)) os.Stdout.Write(data) } handle err { switch err.(type) { case *os.ErrNotExist: // Code... case ...: // ... default: // ... } }
As its more structured, easier to read and less confusing than the draft proposal. Note that the handle could be triggered multiple times just as the original handle version.
But now there's very implicit error checking, you don't know which lines may result in an error, which is something the proposal was trying to avoid.
It's totally different. By your way, you can stop the subsequent operations when an error occurs
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
Hide child comments as well
Confirm
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Eventually you do something like this:
Which I've seen in some other examples as:
To be honest, while this proposed solution works, it still looks like we only saving a few keystrokes. It's good but not great.
That doesn't work for returning errors, though. What if I wanted to return a wrapped version of the error?
Fair enough, but in that case, the wrapping is implicit and it looks like a twisted version of a try/catch block, something that spreads confusion.
I would prefer something like this:
As its more structured, easier to read and less confusing than the draft proposal. Note that the handle could be triggered multiple times just as the original handle version.
But now there's very implicit error checking, you don't know which lines may result in an error, which is something the proposal was trying to avoid.
It's totally different. By your way, you can stop the subsequent operations when an error occurs