Dnia 2021-02-20, o godz. 16:48:09
Michael MacInnis <michael.p.macin...@gmail.com> napisał(a):
> I can tell you most emphatically that I am not proposing not checking
> and/or not handling errors.
I did not stated that you won't. Cited piece was directed at "just return err"
code stressing that it is not that common in the production code, mine's.
> I'd like to know if, for functions like the
> ones just mentioned, a pattern exists for "eliminating
> much of the boilerplate that arises if every error is checked with a rote if
I said twice that for me it is not "boilerplate" but much appreciated feature
of the language whose creators knew and acknowledged that every piece of
code is written once by one developer but is then being read over and over
by way more people than one.
And I have had not less emphatically told that where there is a function
that just returns with err, even in "many places", the bytewise cost of return
is some 30 bytes usually placed by the IDE with three strokes of mine.
For these three strokes where I just return (now):
As a reader I gained clear information that here something was checked then
function just spilled error up *but* I have the surrounding context at sight.
As an author I gained - now or later:
- A ready space to comment on and/or decorate the error value.
- If I am decorating or creating error value, I am right in scope.
- If this is recoverable failure, I can try to recover it now.
> And further if that pattern can be implemented as a library/package
> with acceptable trade offs.
In this thread it was proven that this antipattern can be implemented
as a library/package - using import, then setup, then a call to obscure
function - all to replace a 26 or 30 bytes long idiom - by Michael Ellis.
> I'd like to know if, for functions like the
> If … a pattern exists for "eliminating [ these "ifs" ]
Yes it does exist. I once upon a time did a "fail" package and accompanying
generator to implement such "if-less" pattern to use in a cases where cost
of acquiring a resource is high and a bunch (say 8-10) of such resources is
needed to complete the task. It was a waste of time, as new people need to
be taught to read and understand it anyway. So it was abandoned due to
onboarding issues. It really was not worth the time.
``` go
for fail.With(err) { // bind an error type variable,
s, abort := fail.Simple() // set up a single pass loop
abort.Where(err != nil, !ok, z < 0) // set common "failure" condition(s)
z := z // test z < 0 (a "checked assignment")
r, ok := <-ch // test !ok
x, y, z, err := f(z, r) // test err != nil, then test z < 0
abort.If(x > y) // test x > y (a "plain test")
x, y, err = m(x, y) // test err != nil
return x, y, z, nil // can be prepended by an optional 'pass:'
abort:
fmt.Printf("‖ %s: \t( %s )\n", err.Error(), s.Trig)
return 0, 0, 0, err
}
// output:
‖ failed Test: ( x > y ) // for x > y
‖ failed Assignment: ( !ok ) // for closed ch
‖ failed Assignment: ( z < 0 ) // for z < 0
‖ Whatever err said: ( err != nil ) // for failed f(z, r) and m(x, y)
```
Early iteration (live example) to be seen here:
https://play.golang.org/p/W35BVsZnZ-q
Hope this helps,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
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/20210221171014.2c247c6d%40xmint.
