On Friday, July 28, 2023 at 8:05:03 AM UTC-4 metronome wrote:
Hi,
I came across two questions regarding the hybrid barrier that I am hoping
someone can help with.
1.
Chang https://go-review.googlesource.com/c/go/+/31765 says:
*"It's unconditional for now because barriers on channel
I think the current error handling is just fine.
For the extra typing, they invented keyboard snippets and such.
But for this proposal, I would like to see how a return with multiple
values would look to get a better understanding.
```
// translate this in the proposed solution?
func
Hi,
Using F12 in visual studio code does not find any defintions for the go
code. Go and the visual studio code extenstion are installed.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
Also, errors are values, which means - although uncommon - a function could
return two or more error values. Which would orelse evaluate? Even if you
arbitrarily chose one, that would violate the explicit vs implicit code
flow principle.
My sympathies, OP. I too hate the "if err!= nil"
err := io.Copy(w, r) *orelse* {
w.Close()
os.Remove(dst)
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
My question still stands. Semantically, what value exactly does the
"orelse" condition test is not equal to nil?
- does it test the value from the preceding assignment? If so, is
Another idea: write a handler that wraps whatever handler you usually use.
That handler looks through the Record for attr values of type
*http.Request, and replaces them with whatever formatting you want.
You might even be able to do that with a ReplaceAttr function with the
built-in handlers.
On
Good point Harri,
This is what the correct version will look like using this proposal
func CopyFile(src, dst string) error {
r, err := os.Open(src) *orelse* return fmt.Errorf("copy %s %s: %v", src,
dst, err)
defer r.Close()
w, err := os.Create(dst); *orelse* return fmt.Errorf("copy %s %s:
Apologies if I am not understanding your question, but does not the
compiler know the types of all variables (including the returned
variables)? The compiler will emit code to execute the orelse block if the
error variable (regardless of its name or concrete type) in the preceding
statement is
IMHO, you have used the irrelevant example (== 2nd code block) from Russ
Cox's paper. The paper says:
> This code is not nice, not clean, not elegant, *and still wrong:* like
the previous version, it does not remove dst when io.Copy or w.Close fails.
I want to compare your proposal with the
Typo: should have said
var foo error
r, bar := os.Open(src) orelse return foo // does this do "if foo != nil {
return foo }" ??
On Sunday, 30 July 2023 at 10:20:12 UTC+1 Brian Candler wrote:
> On Sunday, 30 July 2023 at 09:40:25 UTC+1 DrGo wrote:
>
> orelse must return an error (ie satisfies
On Sunday, 30 July 2023 at 09:40:25 UTC+1 DrGo wrote:
orelse must return an error (ie satisfies the error interface); the
specific type and variable name do not matter.
But how does "orelse" perform the check in the first place? Does it look
for the variable named in the return statement?
thanks for the link.
unlike the onErr approach, my proposal does not treat create special-status
identifier; the orelse block is like any other else block
On Sunday, July 30, 2023 at 1:31:09 AM UTC-6 Brian Candler wrote:
On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote:
I looked at the
orelse must return an error (ie satisfies the error interface); the
specific type and variable name do not matter.
although on second thought.. I am not sure that even that restriction is
necessary.
On Sunday, July 30, 2023 at 1:02:04 AM UTC-6 Brian Candler wrote:
Just to be clear: are you
On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote:
I looked at the long list of proposals to improve error handling in go but
I have not seen the one I am describing below.
There is a meta-ticket here: https://github.com/golang/go/issues/40432
Under the section "Simplifications of if err
Just to be clear: are you hard-coding the variable name "err" into the
semantics of "orelse"? That is, you can't assign the error return to a
variable of any other name?
I disagree that this makes the job of linters any easier than it is today.
For example, if you'd written
...
15 matches
Mail list logo
