mal_ls November 18, 2015 at 16:06

“Errors Are Values” in Go and VB Echo

From the sandbox

Fate brought me (a practice programmer, mainly using C #) to a project in which the main functionality is developed on Go.

While studying Go, I drew attention to the unusual practice of error handling. After reading the explanations in the articles, Errors are meanings and Why Goals ’Errors are Values” noted that the solutions offered there recall one feature of Visual Basic that programmers very unflatteringly commented on.

The bottom line is as follows. There are complaints from programmers about checking errors in Go. Let's take an example from the article Errors - these are the values :

_, err = fd.Write(p0[a:b])
if err != nil {
    return err
}
_, err = fd.Write(p1[c:d])
if err != nil {
    return err
}
_, err = fd.Write(p2[e:f])
if err != nil {
    return err
}
// and so on

We see that there is repeating code associated with error handling, which is quite satisfactory. It seems, why not use the standard try-catch practice and the error will be processed in one place?

Further in the article Errors - these values , a solution is proposed:

func (ew *errWriter) write(buf []byte) {
    if ew.err != nil {
        return
    }
    _, ew.err = ew.w.Write(buf)
}
w := &errWriter{w: fd}
ew.write(p0[a:b])
ew.write(p1[c:d])
ew.write(p2[e:f])
// and so on
if ew.err != nil {
    return ew.err
}

Here we see that error handling now happens once. It seems that the code has been simplified.

And then, I got the feeling that there was something similar in history. And it was in Visual Basic and it was connected with the If statement. I will talk about Visual Basic in the past tense, since I have not worked with it for a long time.

In Visual Basic, an If statement was present and, unlike C ++ and Java, the?: Operator was missing. Thus, the following code was written:

Dim a As Integer
If CheckState() Then
	a = 12
Else
	a = 13
End If

There were complaints on the part of VB programmers: a lot of repetitive code, it would be nice to reduce it to one line and be able to use inline. So maybe IIf appeared:

a = IIf(CheckState(), 12, 13)

Everything would be fine, but the people began to grow other indignation, as there was a catch. The fact is that in addition to the code when values are used in IIf, there is a code when functions are indicated in the place of values and it is expected that one of the functions will be called depending on the condition, as in the If statement:

a = IIf(CheckState(), GetTrueAValue(), GetFalseAValue())

And for many programmers, it was a surprise that in this code both functions will be called: GetTrueAValue and GetFalseAValue. Although they expected IIf to work as an If statement (or like?: In C ++), i.e. they did not understand what is the point of calling the second function when its resulting value does not make sense.

It turned out that some programmers at first perceived IIf as an If statement, but in fact IIf turned out to be not an operator, but a function. And to call a function, you need to calculate all its argument, i.e. you will need to call all the specified functions in the arguments. Moreover, IIf was so conveniently pushed that not all programmers immediately recognized that it was not an operator, but a normal function.

The essence of the If statement in Visual Basic (and in other languages) is to determine the sections of code that must be executed depending on the condition. The attempt to use IIf gave only a superficial solution and did not meet the basic expectation of it - to call one or another function depending on the condition.

So here. Let's go back to Go and the practice that we offer for working with bugs. I got the impression that the above error handling practice is very similar to IIf in Visual Basic. Let's expand an example:

w := &errWriter{w: fd}
ew.write(getAB())
ew.write(getCD())
ew.write(getEF())
// and so on
if ew.err != nil {
    return ew.err
}

Accordingly, the question arises here: if an error occurs in the line ew.write (getAB ()), then why getCD () and getEF () are executed when there is no sense in their resulting values?

Why such a question arises? The fact is, an error is a value that determines which code should be executed. And this is clearly seen in the original way of handling errors in Go.

_, err = fd.Write(getAB())
if err != nil {
    return err
}
_, err = fd.Write(getCD())
if err != nil {
    return err
}
_, err = fd.Write(getEF())
if err != nil {
    return err
}

The error value is processed by the if statement. And processing the error value in if just determines what code should be executed next. Moreover, in most cases, for making a decision, it is important to have an error, not its content.

In my opinion, ty-catch-finally just do what they need, determine the code that will be executed depending on the exception that has occurred.

PS: Then I remembered from VB:

On Error Resume Next

But it would be better not to remember. Chur me, chur.

Tags:

“Errors Are Values” in Go and VB Echo

Also popular now: