[go-nuts] Re: [RFC] Yet another proposal for Go2 error handling

[Justin Israel]

On Monday, June 5, 2023 at 4:17:17 AM UTC+12 Shulhan wrote:

Dear gophers, 

I have been reading several proposals about error handling couple of 
months ago and today a light bulb come upon me, and then I write as much 
as I can think. I am not sure if its good or bad idea or even possible 
to implement. 

In this post, I will try as concise as possible. 
The full and up to date proposal is available at 
https://kilabit.info/journal/2023/go2_error_handling/ . 

Any feedback are welcome so I can see if this can move forward. 
Thanks in advance. 

== Background 

This proposal is based on "go2draft Error Handling". 

My critics to "go2draft Error Handling" is the missing correlation 
between handle and check. 
If we see one of the first code in the design, 

 
... 
handle err { 
return fmt.Errorf("copy %s %s: %v", src, dst, err) 
} 

r := check os.Open(src) 
... 
 

There is no explicit link between check keyword and how it will trigger 
handle err later. 
It is also break the contract between the signature of os.Open, that 
return an error in the second parameter, and the code that call it. 

This proposal try to make the link between them clear and keep the code 
flow explicit and readable. 

The goals is not to reduce number of lines but to minimize repetitive 
error handling. 


== Proposal 

This proposal introduces two new keywords and one new syntax for 
statement. 

The two new keywords are “WHEN” and “HANDLE”. 

 
When = "when" NonZeroValueStmt HandleCallStmt . 
NonZeroValueStmt = ExpressionStmt 
; I am not quite sure how to express non-zero value 
; expression here, so I will describe it below. 

HandleCallStmt = "handle" ( HandleName | "{" SimpleStmt "}" ) . 
HandleName = identifier . 
 

The HandleCallStmt will be executed if only if the statement in 
NonZeroValueStmt returned non-zero value of its type. 
For example, given the following variable declarations, 

 
var ( 
err = errors.New(`error`) 
slice = make([]byte, 1) 
no1 = 1 

no2 int 
ok bool 
) 
 

The result of when evaluation are below, 

 
when err // true, non-zero value of type error. 
when len(slice) == 0 // true, non-zero value of type bool. 
when no1 // true, non-zero value of type int. 
when no2 // false, zero value of int. 
when ok // false, zero value of bool. 
 

The HandleCallStmt can jump to handle by passing handle name or provide 
simple statement directly. 
If its simple statement, there should be no variable shadowing happen 
inside them. 

Example of calling handle by name, 

 
... 
when err handle myErrorHandle 

:myErrorHandle: 
return err 
 

Example of calling handle using simple statement, 

 
... 
when err handle { return err } 
 

The new syntax for statement is to declare label for handle and its body, 

 
HandleStmt = ":" HandleName ":" [SimpleStmt] [ReturnStmt | HandleCallStmt] 
. 
 

Each of `HandleStmt` MUST be declared at the bottom of function block. 
An `HandleStmt` can call other `HandleStmt` as long as the handle is above 
the 
current handle and it is not itself. 
Any statements below `HandleCallStmt` MUST not be executed. 

Unlike goto, each `HandleStmt` is independent on each other, one 
`HandleStmt` 
end on itself, either by calling `return` or `handle`, or by other 
`HandleStmt` and does not fallthrough below it. 

Given the list of handle below, 

 
:handle1: 
S0 
S1 
:handle2: 
handle handle1 
S3 
 

A `handle1` cannot call `handle2` because its below it. 
A `handle2` cannot call `handle2`, because its the same handle. 
A `handle2` can call `handle1`. 
The `handle1` execution stop at statement `S1`, not fallthrough below it. 
The `handle2` execution stop at statement "`handle handle1`", any 
statements 
below it will not be executed. 


The following function show an example of using this proposed error 
handling. 
Note that the handlers are defined several times here for showing the 
possible cases on how it can be used, the actual handlers probably only two 
or 
three. 

 
func ImportToDatabase(db *sql.DB, file string) (error) { 
when len(file) == 0 handle invalidInput 

f, err := os.Open(file) 
when err handle fileOpen 
// Adding `== nil` is OPTIONAL, the WHEN operation check for NON zero 
// value of returned function or instance. 

data, err := parse(f) 
when err handle parseError 

err = f.Close() 
// Inline error handle. 
when err handle { return fmt.Errorf(`%s: %w`, file, err) } 

tx, err := db.Begin() 
when err handle databaseError 

// One can join the statement with when using ';'. 
err = doSomething(tx, data); when err handle databaseError 

err = tx.Commit() 
when err handle databaseCommitError 

var outofscope string 
_ = outofscope 

// The function body stop here if its not expecting RETURN, otherwise 
// explicit RETURN must be declared. 

return nil 

:invalidInput: 
// If the function expect RETURN, the compiler will reject and return 
// an error indicating missing return. 

:fileOpen: 
// All the instances 

Re: [go-nuts] 9 is prime if it's a hot day

[Sven Anderson]

Bakul Shah  schrieb am Mo. 5. Juni 2023 um 00:00:

> Find the following paper and all will be revealed! May be.
>
> "Measuring The Primadona Factor For Odd Numbers" by Y. Ronen et al.
>
> PS: I think Rob's explanation is incorrect! 9 is shown to be *not* a
> prime possibly *because* it was a hot day! But given where this was
> published, may be Rob's explanation is indeed the right one :-)
>

Also apparently they are not Easter eggs but Easter rabbit holes. So,
better watch out. ;-)

PPS: I could claim that I deliberately re-routed this thread to golang-dev
to add additional confusion to this mysterious topic, but in reality it was
a simple stupid mistake.


On Jun 4, 2023, at 11:47 AM, Alan Donovan  wrote:
>
> I can't find said article or any reference to the "hot day" phrase.
> Does the deliberate mistake warrant a comment in the HTML source of
> the document so that the answer is there for those who care to look?
>
> On Sun, 4 Jun 2023 at 08:01, Sven Anderson  wrote:
>
>
>
>
> Kamil Ziemian  schrieb am Sa. 3. Juni 2023 um
> 21:13:
>
>
> Is this example found in the "Composite literals" section of Go Spec a
> joke?
> // list of prime numbers
> primes := []int{2, 3, 5, 7, 9, 2147483647}
>
> I checked on the internet and 2147483647 is a prime number (
> https://en.wikipedia.org/wiki/2,147,483,647), so this element is fine.
>
> Best regards
> Kamil
>
>
>
> From https://golang.org/cl/101457
>
> Rob Pike: It's a reference to a legendary article from the Journal of
> Irreproducible Results.
>
> Andrew Bonvente: Is this a hazing ritual for new issue triagers? ;)
>
> Rob Pike: Perhaps. There are details from the earliest parts of the
> project that are deliberately weird, as Easter eggs, if you like.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-dev/CAFwXxZQvPLpjRf-P9o_pzF-nvHRajT4-nfceQvgMZrghE_t6Ww%40mail.gmail.com
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-dev/CACKEwjGpekmnq%2BViUfYp7LWtmg2KErgM5CUjKWRW5XHz-_nSLg%40mail.gmail.com
> .
>
>
>

-- 
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/CAFwXxZTEeYTwzKTX7VhsSMaQ6E6P%2BVBZnn5869nAn7xJVpY2wg%40mail.gmail.com.

Re: [go-nuts] call for data on HTTP routing

[Andrew Harris]

I wanted to make a quick observation w/r/t Ian's suggestion of not 
registering ambiguous patterns. The tradeoff isn't ultimately about what 
behaviors can be associated with what routes, but around what is required 
to register routes. To intentionally use the kinds of routes we'd interpret 
as ambiguous, it might be plausible to (1) register a methodless pattern, 
and move the method-matching into the associated handler. Or, (2) register 
a methodless pattern with e.g. a blanket 404 or 405 handler, and then 
register a the same pattern with a method and a more active handler. Or, 
something else - it would add friction to setting up this kind of routing 
logic (maybe more verbose, maybe more explicit), but not prohibit it.

(1) 
mux.HandleFunc("/foo/", func...
...
if req.Method == http.MethodGet ...
...

(2)
mux.Hanlde("/foo/", notReallyFooHandler)
mux.Handle("GET /foo/", fooHandler)
On Thursday, June 1, 2023 at 2:34:54 PM UTC-7 Ian Lance Taylor wrote:

> On Thu, Jun 1, 2023 at 2:23 PM 'Jonathan Amsterdam' via golang-nuts
>  wrote:
> >
> > The second question is about a specific routing scheme, and here I have 
> no preconceived notions. Here is the context: given two routing patterns 
> that might otherwise conflict, we'd like to allow both by preferring one 
> over the other, where this makes sense. Currently, we prefer a pattern that 
> specifies a method over one that doesn't; and after that, we prefer a 
> pattern with a more specific path. For example,
> >
> > GET /foo/
> >
> > wins over
> >
> > /foo/
> >
> > because the first specifies a method, but it loses to
> >
> > GET /foo/bar
> >
> > because the latter's path is more specific (it matches only "/foo/bar", 
> while "/foo/" matches any path beginning "/foo").
> >
> > Those three patterns make sense together:
> >
> > GET /foo/bar match a specific GET request
> > GET /foo/ match any GET request beginning /foo
> > /foo/ match a request with any method beginning /foo
> >
> > But what about these two patterns:
> >
> > GET /foo/
> > /foo/bar
> >
> > The first pattern specifies a method, but the second has a more specific 
> path. Which should win? Or should this combination be disallowed because 
> it's too confusing? My question is, do any pairs of patterns like this show 
> up in practice? And if so, which one should take precedence?
>
> This is an obvious point, but in general for any case where two
> different patterns can match an HTTP request it is possible to write a
> single pattern that matches both and then let the function
> differentiate based on the precise request. On the other hand, when
> it is unclear which pattern is going to match a specific HTTP request,
> it seems quite possible for the programmer to make a mistake as to
> which one will match, and since the cases are by construction obscure
> it seems easy to fail to detect such a case in testing.
>
> This suggests that one possible approach is to use a very simple
> request matching rule that no reasonable person can misunderstand, and
> for the router to give an error on ambiguous cases.
>
> Ian
>

-- 
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/b90c13c1-5fcd-41a0-aba1-2f529be3828fn%40googlegroups.com.

Re: [go-nuts] Detecting race conditions

['Axel Wagner' via golang-nuts]

I think the race detector is already relatively good at this. Like, AIUI,
it keeps track of the partial order of events and checks if that is
consistent and doesn't *purely* rely on writes actually happen concurrently.
I suspect (based on little) that in this case, the synchronization points
that logging introduces might be more relevant. But I don't know.

On Sun, Jun 4, 2023 at 9:20 PM Stephen Illingworth <
stephen.illingwo...@gmail.com> wrote:

> But it does not introduce false positives. It exposes true positives. The
> race are still there, even if the race detector can not detect them. Note
> that the race detector is a heuristic. It will never find all race
> conditions, only the ones encountered in the actual run.
>
>
> This is a great point. They are true positives.
>
> I wonder if it's possible for the -race detector (via an optional flag) to
> introduce random lag in order to change the execution profile. I'm thinking
> that this would help to flush out these true positives. Fuzz testing but
> specifically for race detection.
>
> --
> 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/8ca3eef8-74b4-4ed3-b9fb-4cc63f5d0a86n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfHP9HQsut_5Sp9atQw4jQHQ1P3cYs1LT%3DHrrT-O0k%3DEzQ%40mail.gmail.com.

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

[Ian Lance Taylor]

On Sun, Jun 4, 2023 at 9:17 AM Shulhan  wrote:
>
> I have been reading several proposals about error handling couple of
> months ago and today a light bulb come upon me, and then I write as much
> as I can think.  I am not sure if its good or bad idea or even possible
> to implement.
>
> In this post, I will try as concise as possible.
> The full and up to date proposal is available at
> https://kilabit.info/journal/2023/go2_error_handling/ .
>
> Any feedback are welcome so I can see if this can move forward.

Thanks.  Perhaps I misunderstand, but this seems to provide a
different way of writing an if statement and a goto statement.
Instead of writing

if err != nil {
goto parseError
}

I can write

when err handle parseError

Any change to error handling is going to affect all Go code
everywhere.  If we change anything it needs to be a big improvement.
It's not worth changing all Go code everywhere for a small
improvement.  After all, Go does work OK today for most people.  It's
not clear to me that this proposal is a big enough improvement.
Thanks.

Ian

-- 
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/CAOyqgcWWCFHG%2B0Ahf6qtCgRrEFe%3DrdAt78ZzpUvY_thXvz8vdA%40mail.gmail.com.

Re: [go-nuts] Detecting race conditions

[Stephen Illingworth]

But it does not introduce false positives. It exposes true positives. The 
race are still there, even if the race detector can not detect them. Note 
that the race detector is a heuristic. It will never find all race 
conditions, only the ones encountered in the actual run.


This is a great point. They are true positives. 

I wonder if it's possible for the -race detector (via an optional flag) to 
introduce random lag in order to change the execution profile. I'm thinking 
that this would help to flush out these true positives. Fuzz testing but 
specifically for race detection.

-- 
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/8ca3eef8-74b4-4ed3-b9fb-4cc63f5d0a86n%40googlegroups.com.

[go-nuts] [RFC] Yet another proposal for Go2 error handling

[Shulhan]

Dear gophers,

I have been reading several proposals about error handling couple of
months ago and today a light bulb come upon me, and then I write as much
as I can think.  I am not sure if its good or bad idea or even possible
to implement.

In this post, I will try as concise as possible.
The full and up to date proposal is available at
https://kilabit.info/journal/2023/go2_error_handling/ .

Any feedback are welcome so I can see if this can move forward.
Thanks in advance.

==  Background

This proposal is based on "go2draft Error Handling".

My critics to "go2draft Error Handling" is the missing correlation
between handle and check.
If we see one of the first code in the design,


...
handle err {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

r := check os.Open(src)
...


There is no explicit link between check keyword and how it will trigger
handle err later.
It is also break the contract between the signature of os.Open, that
return an error in the second parameter, and the code that call it.

This proposal try to make the link between them clear and keep the code
flow explicit and readable.

The goals is not to reduce number of lines but to minimize repetitive
error handling.


== Proposal

This proposal introduces two new keywords and one new syntax for
statement.

The two new keywords are “WHEN” and “HANDLE”.


When = "when" NonZeroValueStmt HandleCallStmt .
NonZeroValueStmt = ExpressionStmt
 ; I am not quite sure how to express non-zero value
 ; expression here, so I will describe it below.

HandleCallStmt   = "handle" ( HandleName | "{" SimpleStmt "}" ) .
HandleName   = identifier .


The HandleCallStmt will be executed if only if the statement in
NonZeroValueStmt returned non-zero value of its type.
For example, given the following variable declarations,


var (
err   = errors.New(`error`)
slice = make([]byte, 1)
no1   = 1

no2 int
ok  bool
)


The result of when evaluation are below,


when err // true, non-zero value of type error.
when len(slice) == 0 // true, non-zero value of type bool.
when no1 // true, non-zero value of type int.
when no2 // false, zero value of int.
when ok  // false, zero value of bool.


The HandleCallStmt can jump to handle by passing handle name or provide
simple statement directly.
If its simple statement, there should be no variable shadowing happen
inside them.

Example of calling handle by name,


...
when err handle myErrorHandle

:myErrorHandle:
return err


Example of calling handle using simple statement,


...
when err handle { return err }


The new syntax for statement is to declare label for handle and its body,


HandleStmt  = ":" HandleName ":" [SimpleStmt] [ReturnStmt | HandleCallStmt] .


Each of `HandleStmt` MUST be declared at the bottom of function block.
An `HandleStmt` can call other `HandleStmt` as long as the handle is above the
current handle and it is not itself.
Any statements below `HandleCallStmt` MUST not be executed.

Unlike goto, each `HandleStmt` is independent on each other, one `HandleStmt`
end on itself, either by calling `return` or `handle`, or by other
`HandleStmt` and does not fallthrough below it.

Given the list of handle below,


:handle1:
S0
S1
:handle2:
handle handle1
S3


A `handle1` cannot call `handle2` because its below it.
A `handle2` cannot call `handle2`, because its the same handle.
A `handle2` can call `handle1`.
The `handle1` execution stop at statement `S1`, not fallthrough below it.
The `handle2` execution stop at statement "`handle handle1`", any statements
below it will not be executed.


The following function show an example of using this proposed error handling.
Note that the handlers are defined several times here for showing the
possible cases on how it can be used, the actual handlers probably only two or
three.


func ImportToDatabase(db *sql.DB, file string) (error) {
when len(file) == 0 handle invalidInput

f, err := os.Open(file)
when err handle fileOpen
// Adding `== nil` is OPTIONAL, the WHEN operation check for NON zero
// value of returned function or instance.

data, err := parse(f)
when err handle parseError

err = f.Close()
// Inline error handle.
when err handle { return fmt.Errorf(`%s: %w`, file, err) }

tx, err := db.Begin()
when err handle databaseError

// One can join the statement with when using ';'.
err = doSomething(tx, data); when err handle databaseError

err = tx.Commit()
when err handle databaseCommitError

var outofscope string
_ = outofscope

// The function body stop here if its not expecting RETURN, otherwise
// 

Re: [go-nuts] Equivalence of types declared with equals

[Duncan Harris]

Thanks. So the only issue is that maybe the error message is a bit
sub-optimal.

Duncan


On Sun, 4 Jun 2023 at 06:35, Axel Wagner 
wrote:

> That's a type alias, though. Not a type definition.
>
> The real issue is this part of the spec
> :
>
>> Two struct types are identical if they have the same sequence of fields,
>> and if corresponding fields have the same names, and identical types, and
>> identical tags. *Non-exported field names from different packages are
>> always different*.
>>
> So the two `struct{ f string }` are not identical, because they don't have
> the same same sequence of fields with the same names - the two "f" names
> are different, as they are from different packages.
>
>
>
> On Sun, Jun 4, 2023 at 2:19 AM Kurtis Rader  wrote:
>
>> See https://go.dev/ref/spec#Type_definitions and
>> https://go.dev/ref/spec#Type_identity. In particular this statement: "The
>> new type is called a *defined type*. It is different
>>  from any other type, including
>> the type it is created from."
>>
>> On Sat, Jun 3, 2023 at 5:03 PM Duncan Harris  wrote:
>>
>>> Why does this not work?
>>>
>>> https://go.dev/play/p/dodUj441xJS
>>>
>>> Produces the rather strange error message:
>>>
>>> ./prog.go:7:6: cannot use []t{…} (value of type []struct{f string}) as
>>> []struct{f string} value in argument to m.F
>>>
>>> --
>>> 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/396c63a7-4b0c-4f5e-8c0e-a1e45249e247n%40googlegroups.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
>> --
>> 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/CABx2%3DD8xgRUXQxOpzTuubqMg%3DN_m98VMUHGJUhXF4hMNqA8taQ%40mail.gmail.com
>> 
>> .
>>
>

-- 
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/CAJFQHaSTx4GJBFKaJWfvPSAfZN3T7EV0SRJGpcYVQ%3D1L_30TMQ%40mail.gmail.com.

Re: [go-nuts] If a pointer type implements a method in an interface, then its value type variable cannot be assigned to the corresponding interface. But it works the other way around!

[王谦铭]

Thanks for your explanation.

Ian Lance Taylor  于2023年6月4日周日 01:09写道：

> On Sat, Jun 3, 2023 at 10:05 AM 王谦铭  wrote:
> >
> > If a pointer type implements a method in an interface, then its value
> type variable cannot be assigned to the corresponding interface.
> Conversely, if a value type implements a method in an interface, its
> pointer type variable can be assigned to the corresponding interface.
> > I want know why that can work? Just like the code.
>
> Please paste code as plain text or as a link to the Go playground.  Thanks.
>
> In Go every value method--that is, every method with a value
> receiver--is also valid for the pointer type.  See
> https://go.dev/ref/spec#Method_sets .
>
> Ian
>

-- 
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/CAJneERqEAMsJV-2FMoPx9F2cQGdtjFqJp8X57DyX0xW%3DN9Wx7w%40mail.gmail.com.

Re: [go-nuts] Detecting race conditions

['Axel Wagner' via golang-nuts]

Yes, logging changes behavior so that races might get exposed, both by
slowing down the program and by introducing implicit synchronization points
(the writes to the output happen under a mutex, AFAIK).

But it does not introduce false positives. It exposes true positives. The
race are still there, even if the race detector can not detect them. Note
that the race detector is a heuristic. It will never find all race
conditions, only the ones encountered in the actual run.

On Sat, Jun 3, 2023 at 9:54 PM Levi Durfee  wrote:

> Hello,
>
> While I was looking into a rarely occurring panic I used delve to debug
> the application. I set some log points in the Go standard library. I put
> one long point in src/net/lookup.go on line 298 so I could see that lookups
> were happening.
>
> I passed "-race" to the delve "build-flags" option so I could detect race
> conditions.
>
> I was able to find the race condition causing my panic and fix it, but I
> also noticed some other race conditions. *I only see these race
> conditions when I have a log point set. *The race conditions are in my
> code.
>
> While it's easy to fix these race conditions in my code, I wonder if the
> log point might produce false positives. I've read that the Go race
> detector messages should not be taken lightly.
>
> Could the log points be modifying the behavior, maybe slowing it down
> enough, so when debugging my app it has the opportunity to see the race
> conditions?
>
> I'm using Go 1.20.4
>
> https://github.com/golang/go/blob/go1.20.4/src/net/lookup.go#L298
>
> Thanks,
> Levi
>
> --
> 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/4ea76bb3-57f5-42fa-8bce-249135161607n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfE%2BG8Kf3ciWV3KZ13VW-YzC8sqt8JOmU8Ub9pvCRVQndg%40mail.gmail.com.