I really do not like code like
defer func() {
if cerr := f.Close(); cerr != nil && err == nil {
err = cerr
}
}()
My problem with this code is:
1) It is ugly
2) It is too clever
3) It is not clear what the code actually does
4) It is a trap for maintainers of the code
This code _se
On Sat, Jan 30, 2021 at 4:35 PM eafea eaef wrote:
>
> I'm trying to build my own Fort Rango.
> One of the requirements for this project is to not import "C".
> If I use the official go compiler with "go tool compile", it will output an
> object file in its own format!
> I'm wondering if I can use
I'm trying to build my own Fort Rango.
One of the requirements for this project is to not import "C".
If I use the official go compiler with "go tool compile", it will output an
object file in its own format!
I'm wondering if I can use the official go compiler to produce elf format
object files.
Hi Mike,
Thank you for your consideration. I think you exactly got the essence of my
question: How do I wait on all go routines to finish (or be blocked on one
or more channels) before advancing time.
A key thing I would like from such a solution is that it does not require
too heavy modification
You need to think about how important it is for the user of your function
or method to know about the Close error. Usually when a function closes a
resource it also acquires it, so your caller cannot do anything to fix the
closure. So I report only the first error.
The question that is more dif
Is there some idiomatic or well known way to deal with extra errors when
you are already recovering from or reporting an error condition?
The typical case is, you hit an error and need to release resources before
returning it. But the resources themselves may fail when closing them.
One (freque
