Problems with try:
1 - hiding the return
2 - error decoration
The motivation behind this "issue" seems somewhat suspect. I get the
consensus the idea that people think the current state of the art `if err
!= nil { .. }` its verbose. I'd argue that isn't the issue with it. If we
want to be robust we need to check these errors, its nice to not have magic
obscuring this (exceptions). I'd argue that the main issue with this
"boiler plate" is it clutters up our happy path. I'd propose we just move
the error handling away from the error value, but not to far.
I present the `try block`:
try {
v1, v2, err := thing()
return v1, v2
err: {
return fmt.Errorf("thing failed with %v", err)
}
}
So try is allowing any `error` type to also be a label, it also checks that
value on asignment, if it isn't `nil` it jumps to the label. All error
handling code still has proper scope to the function. The code dealing with
errors is just moved out of the happy path so we can see what is going on.
Here is a bigger example:
func ReadConfig(file string) (*Config, error)
try {
f, e_open := os.Open(file)
defer goto d_close // would be nice if this existed too
c := &Config{}
data := make([]byte, 256)
retry := 0
READ:
n, e_read := f.Read(data)
PARSE:
done, e_parse := configParse(c, data[0:n])
if !done {
goto READ
}
return c, nil
e_open: {
return nil, fmt.Errorf("config: `%v` open error %v", file,
e_open)
}
e_read: {
if io.EOF == e_read {
if n > 0 {
goto PARSE
}
return nil, fmt.Errorf("config: `%v` invalid config;
expected more data", file)
}
if io.ShouldRetry(e_read) && retry < 10 {
retry++
time.Sleep(retry * 100)
goto READ
}
return nil, fmt.Errorf("config: `%v` reading failed cause %v",
file, e_read)
}
e_parse: {
return nil, fmt.Errorf("config: `%v` failed to parse: %v", file,
e_parse)
}
d_close: {
if err := f.Close(); err != nil {
log.LogError("config: `",file,"` err on close: ", err)
}
}
}
}
The eager EOF check, is some illistration of still having control of error,
although I believe go doesn't do this. Returns are still visible, scope
isn't too wild.
`defer goto` is in here too to participate in the uncluttering since its
also noisy and messy if you have a complicated defer.
--
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/5a45f4b2-e4e5-42ce-92a1-ff54ca58aac8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
