I did not see clear and simple either. As I wrote, I don't like complex
solutions. Just trying to ask: why we don't have simple solution. The
function just simple example, this isn't a draft or something.
On Friday, 31 July 2020 at 23:25:26 UTC+3 b.ca...@pobox.com wrote:
> 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/2c661dd6-5c2c-4156-be01-3bb7bef9852bn%40googlegroups.com.
