On Friday, 31 July 2020 15:06:33 UTC+1, semi...@gmail.com wrote:
>
> I know, there are so many discussion about error handling. I read tons of
> idea about that. Looks like most of idea rejected from community but every
> idea brings our goal closer.
>
The more I use go's existing error handling, the more I like it.
It's clear and it's explicit. Could a function return an error, or not?
It's right there in the function signature. It's something you can't
ignore.
foo := func() // fails to compile if foo returns two values
foo, err := func() // OK, but will fail if you don't use the 'err'
value
foo, _ := func() // explicitly ignore the error: a big code smell
signal
You then make a decision as to what to do. Should I just return from my
own function and let the error propagate up unchanged? Should I propagate
a new error which wraps or replaces the original error? Should I do
something else?
There have been dozens of proposals for changing it, and I've not seen one
which is as clear or as simple.
For your "throws func" - you didn't describe the semantics. I am guessing
it is intended to be equivalent to the following?
func myFileRDWRFunc(filename string) (string, error) {
f, err := os.OpenFile(filename, os.O_RDWR, 0600)
if err != nil { // backward compatibility (??)
return "", err
}
err = f.WriteString("anystring")
if err != nil {
log.Println(err)
f.Close()
return "", err
}
err = f.Seek(0, 0)
if err != nil {
log.Println(err)
f.Close()
return "", err
}
b, err := ioutil.ReadAll(f)
if err != nil {
log.Println(err)
f.Close()
return "", err
}
return string(b), nil
}
That is: I think you're saying IF there's a multi-valued function return,
AND the last value is an error, THEN it will silently consume that value,
and jump to the handler if not nil. Is that correct? What about functions
which return multiple values but the last one is not an error? What
happens if the handler doesn't have a "return" statement - does it continue
where it left off??
Aside: I don't think putting f.Close() in the error handler is right.
There should be "defer f.Close()" as soon as the file has been opened - so
that it is closed both in normal and error conditions.
--
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/9e8adbbf-dbb2-42f1-bc72-4cc2ee939269o%40googlegroups.com.
