Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Dan Kortschak]

This is what the go version directive in go.mod is for.

On Mon, 2019-07-15 at 20:05 -0700, Andrey Tcherepanov wrote:
> Or... adding "require" to package statement to indicate Go 2 is the 
> language for this file
> 
> package main requires "go2"

-- 
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/e0c1cf01495cbad513d4fe7c34d20cc545dfb092.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Andrey Tcherepanov]

Thank you Roger, it is kind of funny how natural that syntax is that couple 
people use it so naturally.

But with all of these ... it is impossible to squeeze them into Go (even 2) 
without breaking backward compatibility. Unless we will add something that 
will take nil from pointers, something like

func f() (v interface{} | !nil) {
... // this function never returns nil
}

Or... adding "require" to package statement to indicate Go 2 is the 
language for this file

package main requires "go2"

or just

package main "go2"

on top of the file. Or new extension "go2" for the files ... or identify it 
in go.mod... 

But anyway - if we want the new "pointer | nil" to be expressed as is, some 
rather big changes will be needed, and I do not see it ever happening 
without forking the language. Yes, I am that pessimistic



On Sunday, July 14, 2019 at 12:53:52 AM UTC-6, rog wrote:
>
> On Fri, 12 Jul 2019, 07:22 Sam Whited, > 
> wrote:
>
>>
>>
>> On July 12, 2019 4:35:54 AM UTC, Andrey Tcherepanov <
>> xnow4f...@sneakemail.com > wrote:
>> >What these guys are proposing in that paper would be closer to
>> >(Go-style)
>> >func f() (v value | e error) { ... }
>> >
>> >(where "|" could be read as "or" or "union")
>> >
>>
>> I've thought a tiny bit about how union or sum types would work in Go 
>> using a similar syntax. My initial thoughts are here in case this is of 
>> interest to anyone else:
>>
>> https://blog.samwhited.com/2019/06/go-and-sum-types/
>
>
> As far as I can tell, that's almost identical to the scheme that I 
> suggested here: 
> https://github.com/golang/go/issues/19412#issuecomment-288485048
>
>
>>
>> —Sam
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/2858C8AA-F25B-4415-A8D4-753DA679EC27%40samwhited.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/5f537183-0fb6-47e0-8a2e-844b540e1014%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Sam Whited]

On Sun, Jul 14, 2019, at 06:53, roger peppe wrote:
> As far as I can tell, that's almost identical to the scheme that I
> suggested here:
> https://github.com/golang/go/issues/19412#issuecomment-288485048

I hadn't seen that issue, I'll have to read through it. Thanks
for the link!

—Sam

-- 
Sam Whited

-- 
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/20f8852e-50b6-4b80-83e3-7b6de3cbc919%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[roger peppe]

On Fri, 12 Jul 2019, 07:22 Sam Whited,  wrote:

>
>
> On July 12, 2019 4:35:54 AM UTC, Andrey Tcherepanov <
> xnow4fippy...@sneakemail.com> wrote:
> >What these guys are proposing in that paper would be closer to
> >(Go-style)
> >func f() (v value | e error) { ... }
> >
> >(where "|" could be read as "or" or "union")
> >
>
> I've thought a tiny bit about how union or sum types would work in Go
> using a similar syntax. My initial thoughts are here in case this is of
> interest to anyone else:
>
> https://blog.samwhited.com/2019/06/go-and-sum-types/


As far as I can tell, that's almost identical to the scheme that I
suggested here:
https://github.com/golang/go/issues/19412#issuecomment-288485048


>
> —Sam
>
> --
> 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/2858C8AA-F25B-4415-A8D4-753DA679EC27%40samwhited.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAJhgacjNskL%3DCO%2Bux0NqLptUZdse9ZX6T-Tsd4fTgnK%2BXv8yxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Sam Whited]

On Fri, Jul 12, 2019, at 06:31, Andrey Tcherepanov wrote:
> I haven't seen your proposal before, but it looks interesting - you
> seem to have put quite a thought into it already.

To be clear, this isn't actually a proposal. I was just toying with the
idea and there's really not much thought put into it; an actual
proposal would need a lot more work than what I've done here to make
sure it's complete and integrates well with the rest of the language.

—Sam

-- 
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/41890755-c472-4563-8935-3337a6e0ca2b%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Andrey Tcherepanov]

Thanks Sam, 

I haven't seen your proposal before, but it looks interesting - you seem to 
have put quite a thought into it already. 

Funny how these seems to be far-sided things - error handling, generics, 
sum types - are coming all related to each other at the end of the day...

Andrey

On Friday, July 12, 2019 at 12:22:42 AM UTC-6, Sam Whited wrote:
>
>
>
> On July 12, 2019 4:35:54 AM UTC, Andrey Tcherepanov <
> xnow4f...@sneakemail.com > wrote: 
> >What these guys are proposing in that paper would be closer to 
> >(Go-style) 
> >func f() (v value | e error) { ... } 
> > 
> >(where "|" could be read as "or" or "union") 
> > 
>
> I've thought a tiny bit about how union or sum types would work in Go 
> using a similar syntax. My initial thoughts are here in case this is of 
> interest to anyone else: 
>
> https://blog.samwhited.com/2019/06/go-and-sum-types/ 
>
> —Sam 
>

-- 
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/901bda6a-38a8-4213-9516-68e24dc6b440%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Bakul Shah]

I didn't quite get that. Sum-types is an independent issue (and can be made to 
work with try!).

They seem to be using a slightly different definition of an error. They are 
saying an error is when a function fails even when all its preconditions are 
met. If the preconditions are not met, and the function fails to perform, it is 
not an error but something else.

I tend to think the distinction is not very useful. If a function fails to 
perform in spite of all preconditions being met, it is either a runtime 
hardware error or a bug. Even in this case one can recover but the cost may be 
high. Think of triple redundancy or just shipping off partial state to another 
machine (provided you have checkpointed) or any number of other things. It used 
to be that if a disk read failed a program had to fail but then we got RAID and 
ZFS etc. It all depends on context and available technology and cost.

I also tend to think things won't be very different in 10 years. There have 
been papers going back 40-50 years that talk about systematic error handling 
and recovery. There was this idea of "recovery blocks" where you use a fast 
algorithm that works correctly in most of the cases but if it fails (and you 
need checking software for it), you give the same problem to an alternate but 
slow code. Great idea but a) this is expensive and b) may not be possible in 
general.

> On Jul 11, 2019, at 9:35 PM, Andrey Tcherepanov 
>  wrote:
> 
> Thank you very much for pointing to that paper! Somehow I think it will be 
> referenced in the future with a prefix "seminal" :)
> 
> What these guys are proposing in that paper would be closer to (Go-style)
> func f() (v value | e error) { ... }
> 
> (where "|" could be read as "or" or "union")
> 
> with that in mind , the call to f might be something like
> 
> v := f() 
> 
> if e := v.(error) {
>   ...
> }
> 
> A.
> 
> On Monday, July 1, 2019 at 12:46:29 AM UTC-6, Sanjay wrote:
> 3 of the most well-known new languages in the past decade (Swift, Rust, and 
> Go, respectively) have all eschewed exceptions for control flow in favor of 
> some sigil in the source code to propagate errors explicitly. Swift uses 
> try-statements (along with a few other control flow constructs), Rust uses 
> the "?" operator (previously the try! macro), and Go uses "if err != nil".
> 
> C++, a language which does have exceptions, has significant fractions of its 
> user base which disable exception support entirely (20% according to a 
> survey) or partially (52%). Google, for instance, almost invariably compiles 
> with -fno-exceptions and uses macros to propagate errors explicitly (see 
> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
>  
> 
>  to get a sense for how that works). Herb Sutter, one of the well-known 
> members of the C++ standards committee from Microsoft, has proposals out to 
> make propagating exceptions require a visible sigil in the source code (also 
> a "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 
>  (an interesting talk overall, I've 
> linked to the specific relevant time). His actual proposal paper is also an 
> interesting read: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf 
> . In a 
> table with the following introduction "This section lays out what I believe 
> are ideal error handling characteristics. They are not unique to C++; I 
> believe they apply to most modern languages", he lists "Unhandled error 
> propagation is visible" as something not provided by C++ exceptions today.
> 
> It's possible that a decade from now, this will all have been a minor blip, 
> and you will eventually be proven right. But at the very least, this context 
> that should inform your priors.
> 
> Sanjay
> 
> PS - checked exceptions don't really have a great leg to stand on either 
> (e.g. consider their interaction with Java 8's streams: 
> https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams 
> , 
> or consider that both Scala and Kotlin don't implement support for them at 
> all) 
> 
> On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote:
> I’ve developed systems that wrap checked exceptions in unchecked ones, but in 
> every case I can think of it was to “abort to the top” - returning control 
> (or exiting) - it is a specialized case of the re-throw, but I would argue it 
> is rarely used in anything other than framework type code, with applications 
> code typically wrapping the specific exception in an “higher-level 
> application checked exception”, that the upper layers handle (possibly 
> inspecting the “cause” exception. 
> 
> As to not answering the question about transf

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Sam Whited]

On July 12, 2019 4:35:54 AM UTC, Andrey Tcherepanov 
 wrote:
>What these guys are proposing in that paper would be closer to
>(Go-style)
>func f() (v value | e error) { ... }
>
>(where "|" could be read as "or" or "union")
>

I've thought a tiny bit about how union or sum types would work in Go using a 
similar syntax. My initial thoughts are here in case this is of interest to 
anyone else:

https://blog.samwhited.com/2019/06/go-and-sum-types/

—Sam

-- 
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/2858C8AA-F25B-4415-A8D4-753DA679EC27%40samwhited.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Andrey Tcherepanov]

Thank you very much for pointing to that paper! Somehow I think it will be 
referenced in the future with a prefix "seminal" :)

What these guys are proposing in that paper would be closer to (Go-style)
func f() (v value | e error) { ... }

(where "|" could be read as "or" or "union")

with that in mind , the call to f might be something like

v := f() 

if e := v.(error) {
  ...
}

A.

On Monday, July 1, 2019 at 12:46:29 AM UTC-6, Sanjay wrote:
>
> 3 of the most well-known new languages in the past decade (Swift, Rust, 
> and Go, respectively) have all eschewed exceptions for control flow in 
> favor of some sigil in the source code to propagate errors explicitly. 
> Swift uses try-statements (along with a few other control flow constructs), 
> Rust uses the "?" operator (previously the try! macro), and Go uses "if err 
> != nil".
>
> C++, a language which does have exceptions, has significant fractions of 
> its user base which disable exception support entirely (20% according to a 
> survey) or partially (52%). Google, for instance, almost invariably 
> compiles with -fno-exceptions and uses macros to propagate errors 
> explicitly (see 
> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
>  to 
> get a sense for how that works). Herb Sutter, one of the well-known members 
> of the C++ standards committee from Microsoft, has proposals out to make 
> propagating exceptions require a visible sigil in the source code (also a 
> "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an 
> interesting talk overall, I've linked to the specific relevant time). His 
> actual proposal paper is also an interesting read: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a 
> table with the following introduction "This section lays out what I believe 
> are ideal error handling characteristics. They are not unique to C++; I 
> believe they apply to most modern languages", he lists "Unhandled error 
> propagation is visible" as something not provided by C++ exceptions today.
>
> It's possible that a decade from now, this will all have been a minor 
> blip, and you will eventually be proven right. But at the very least, this 
> context that should inform your priors.
>
> Sanjay
>
> PS - checked exceptions don't really have a great leg to stand on either 
> (e.g. consider their interaction with Java 8's streams: 
> https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, 
> or consider that both Scala and Kotlin don't implement support for them at 
> all) 
>
> On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote:
>>
>> I’ve developed systems that wrap checked exceptions in unchecked ones, 
>> but in every case I can think of it was to “abort to the top” - returning 
>> control (or exiting) - it is a specialized case of the re-throw, but I 
>> would argue it is rarely used in anything other than framework type code, 
>> with applications code typically wrapping the specific exception in an 
>> “higher-level application checked exception”, that the upper layers handle 
>> (possibly inspecting the “cause” exception. 
>>
>> As to not answering the question about transferring across Go routines, I 
>> apologize. It was not intentional - I read the statement a few times and 
>> didn’t quite get the concern - and meant to get back to it and forgot - but 
>> I read it again a few times and still don’t understand the problem. 
>>
>> What is particular about Go that makes this difficult? It is pretty 
>> common practice to pass exceptions across threads in Java and C++ - e.g. 
>> fork/join and the worker thread throws an exception - the exception is 
>> passed to the joining thread. Conceptually, it is as if the function was 
>> called serially and the exception thrown at the fork point. In these cases 
>> the exception is wrapped, but it has to be because of the strong type 
>> system. It is also pretty trivial to declare a wrapper function that 
>> declares the checked exceptions for clarity - this is done routinely in rpc 
>> using proxies. 
>>
>> > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  
>> wrote: 
>> > 
>> > On Sun, Jun 30, 2019 at 5:23 PM robert engels  
>> wrote: 
>> >> 
>> >> I am going to disagree here. I don’t think ‘checked exceptions’ 
>> exhibit this behavior. Addressing the points from the Joeal  article, 
>> > 
>> > Checked exceptions address some of the difficulties with exceptions. 
>> > However, they introduce new difficulties, and I do not believe they 
>> > work in large-scale programs.  In practice, checked exceptions 
>> > degenerate into unchecked exceptions.  Changing the set of exceptions 
>> > that a function throws forces all callers to adjust their set of 
>> > exceptions.  In practice this is so painful that programs catch 
>> > exceptions and turn into them into unchecked exceptions.  There are a 
>> > number of discussions on the Interwebs about the problems with checked 
>> >

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Nicolas Grilly]

On Tue, Jul 9, 2019 at 4:44 PM Space A.  wrote:

> Did you ever read below the title
>

Yes, I did. I even read the full proposal, all the comments and related
issues in the issue tracker, and all the messages in this thread and other
threads on golang-nuts. This is why I wrote this message :-)

-- 
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/CAG3yVS6SbxSsD4jxft3s1X0i%3DUnGfjNWQ3_uCbay1vcob%3Dn4TQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Space A.]

Did you ever read below the title, or just seen the heading and immediately
start this teachings of emotional posts in your emotional write-up? Some
ppl see more, e.g. they can see what is the destination after first step
made. It's not the fist time ever, when someone trying to "improve" the
language by better error handling or bloody generics.


 > But instead of bringing constructive arguments to improve the proposal,
many comments are about killing the proposal, "leave if != err alone", and
change nothing. These comments summon the "community", but I'm afraid it's
not the kind of community I want to be in.

-- 
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/CADKwOTegwxFtk1stvsDouCKuYjAnHUxHx1vNX6BmQr9Agvyv3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Nicolas Grilly]

On Tuesday, July 9, 2019 at 12:44:12 PM UTC+2, ohir wrote:
>
> Harsh reactions stem from what experienced programmers see as `unintended 
> consequences`
>

Don't you think that the "experienced programmers" composing the Go team 
are also able to foresee and assess the consequences of the try proposal?

-- 
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/272c4fa5-8292-41d3-af6e-8aced5d5ce68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Wojciech S. Czarnecki]

On Tue, 9 Jul 2019 02:26:03 -0700 (PDT)
Nicolas Grilly  wrote:

> try is just syntactic sugar for `if err != nil { return ..., err }` and 
> nothing more. 

Unfortunately it is NOT. 

It (`try`) does magical things to the return parameters, ie. it elides
the last one but only if it is **not** in the scope of the upper level `try`
otherwise it morphs into the naked return. Hardly a "sugar".

> try doesn't change the language grammar and semantics at all: 
> - error handling is still explicit;

Error handling becomes implicit and `try` demands special shape
off the surrounding code (named return parameters, decorating
must be done in a defer) 

> - error are still values;
yes.
> - there is still no stack unwinding;
There is a defer must unless `try` is meant only for pushing the error upstack.

> - etc. 
etc.

> The comparison with exceptions (and anonymous goto statements) is 
> completely uncalled for.
If it was a pin to my proposal, in the https://github.com/golang/go/issues/32968
all labels are named and to be seen plain in all ast tools (eg. cover). 

> I'm baffled by the amount of negative emotions, strong feelings and harsh 
> reactions to the addition of a minor built-in function whose sole goal is 
> to reduce verbosity by factoring out a repetitive pattern.

This is a stated goal. Harsh reactions stem from what experienced programmers
see as `unintended consequences`, namely unstoppable and widespread abuse of 
`try`
(put into several level deep matrioshkas).

> So please fellow gophers, continue to tell the Go team what you'd want to 
> be improved in the try proposal, but have a little faith in their work :-)
I still have. 

-- 
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/20190709124333.0a455b1f%40zuzia.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Nicolas Grilly]

On Monday, July 1, 2019 at 8:46:29 AM UTC+2, Sanjay wrote:
>
> His actual proposal paper is also an interesting read: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf.
>

This is fascinating read about language design in general and error 
handling in particular. Thanks for sharing. 

-- 
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/b85e005e-62f1-4b9a-903d-2ac8e173d7c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Nicolas Grilly]

On Saturday, July 6, 2019 at 12:22:33 AM UTC+2, Jakub Labath wrote:
>
> Some of us had to fix so much broken java/python code with invisible and 
> anonymous goto statements (aka exceptions) that even just seeing the 
> keyword try prompts a physical reaction.
>

"Just seeing the keyword try prompts a physical reaction"?… Maybe this is 
the issue with this discussion: too much emotions, not enough rational 
arguments. 

try is just syntactic sugar for `if err != nil { return ..., err }` and 
nothing more. 

try doesn't change the language grammar and semantics at all: 
- error handling is still explicit;
- error are still values;
- there is still no stack unwinding;
- etc. 

The comparison with exceptions (and anonymous goto statements) is 
completely uncalled for.

I'm baffled by the amount of negative emotions, strong feelings and harsh 
reactions to the addition of a minor built-in function whose sole goal is 
to reduce verbosity by factoring out a repetitive pattern.

I'm seeing people lecturing the Go team about the "language philosophy" and 
submitting "alternative proposals" without understanding the difference 
between a keyword, a built-in function and a statement…

Maybe the try proposal is not perfect and maybe it needs to be improved. 
It's open to discussion. The Go team has made it clear they will listen, as 
they already did in the past with the check/handle proposal. But instead of 
bringing constructive arguments to improve the proposal, many comments are 
about killing the proposal, "leave if != err alone", and change nothing. 
These comments summon the "community", but I'm afraid it's not the kind of 
community I want to be in.

I have an immense respect for the design documents produced by the Go team 
these last few years on many subjects: garbage collection, dependency 
management, error handling, generics, etc. This is exactly the kind of 
engineering I want to see and that made me use Go.

So please fellow gophers, continue to tell the Go team what you'd want to 
be improved in the try proposal, but have a little faith in their work :-)

-- 
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/e337d6d6-3e73-4132-9776-11c904fabe5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Jakub Labath]

I have no doubt there is huge amount of people who love the exceptions, and 
I agree with you 
that is precisely this crowd that pushed this agenda forward.

But I found following true, anything that can fail will fail. E.g. any type 
of IO operation.
It's not a question of if but when.

What that means I have a problem when people think IO Error is an 
exceptional state of some kind.
It is not, it's just valid return value of the given IO operation, if I 
think of it as such I write code that is more reliable and testable.

As for panic/recover - given the above when would I really want to panic? 
If I treat my errors as first class citizens, I don't ever need to panic.
And for the record I myself have on few occasions reached for panic (this 
will never happen type of thinking) - and I found myself going back and 
replace it
with proper error handling every single time. So now I just know better.

As for the argument that it is possible to use try/catch type of error 
handling  successfully.
I say I don't doubt it - I just never had the pleasure to work with (or 
after) anyone that was able to do that.
And I include my own try/catch code in that group.


On Sunday, July 7, 2019 at 5:37:38 AM UTC, Lucio wrote:
>
> On 7/6/19, Jakub Labath > wrote: 
> > "And yes go does have panic/recover - but I never use them for the same 
> reasons I 
> > dislike exceptions. It's just really hard to reason about such jumps in 
> logic especially 
> > in massively concurrent programs that go allows us to write." 
>
> I agree with everything else you state, except the above. 
>
> Those who are comfortable with try/catch and similar should seek their 
> comfort zone in panic/recover and teach some of us why they find them 
> useful. 
>
> Note that I am not one of those. But a lot of the needling that led to 
> "try - the function" almost certainly originates from those quarters 
> and only a little social engineering in the form of great 
> documentation may be needed to put that dragon back to sleep. I vote 
> we encourage that. 
>
> Lucio. 
>

-- 
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/4052c175-b34e-476b-8e31-90695bed924e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Lucio De Re]

On 7/6/19, Jakub Labath  wrote:
> "And yes go does have panic/recover - but I never use them for the same 
> reasons I
> dislike exceptions. It's just really hard to reason about such jumps in logic 
> especially
> in massively concurrent programs that go allows us to write."

I agree with everything else you state, except the above.

Those who are comfortable with try/catch and similar should seek their
comfort zone in panic/recover and teach some of us why they find them
useful.

Note that I am not one of those. But a lot of the needling that led to
"try - the function" almost certainly originates from those quarters
and only a little social engineering in the form of great
documentation may be needed to put that dragon back to sleep. I vote
we encourage that.

Lucio.

-- 
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/CAJQ9t7hVr5CRJFkR6LPGZbFWyRPr9KGBvBa5U1-pdz6va7HH9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Michael Ellis]

> Exception handling when properly done is beautiful.
Yes and so are:

   - C++ templates
   - Python meta-classes
   - Scheme hygienic macros

but that doesn't mean Go would be improved by adding them.

On Friday, July 5, 2019 at 6:46:49 PM UTC-4, robert engels wrote:
>
> If you’ve suffered through bad code due to exceptions, you would just be 
> trading one ill for another. Exception handling when properly done is 
> beautiful. Yes, a lot of people get it wrong, but they would probably get a 
> lot of other things wrong as well. At least with exceptions, you have a 
> stack trace - usually - :) - to help you figure out what they did wrong. 
>
> > On Jul 5, 2019, at 5:29 PM, andrey mirtchovski  > wrote: 
> > 
> >> So I was quiet on the topic then - I am not now. 
> > 
> > i guess you missed the point where I advocated for a new survey, well 
> > advertised, where all the people who are fervent Go programmers but 
> > somehow neglected to fill out the Go surveys for three years running 
> > can cast their voice. "does go error handling need change: ◻️yes ◻️no 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAK4xykXEtQZKeqyC8kLoHfokySD2xDzqY91hTz9_hMX%3DdkKtQg%40mail.gmail.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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/c1c2b2db-b847-4cd9-80a6-317603d870d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

- Other: [ ]

On Fri, Jul 5, 2019 at 5:12 PM Jakub Labath  wrote:
>
> But it's not a binary question.
>
> If you ask me
>
> Would like go to have Maybe/Option type instead of val, err - then I can say 
> yes.
> Would you like to have something such as Rust's Result instead of val, err - 
> then I can say yes (even though I understand this may not be possible due to 
> generics etc).
>
> But what is being asked here is would you like to have error handling and 
> flow of control functionality baked together - and then my answer is no.
>
> I know from several years of experience writing both go and python/java that 
> my go code is more stable than my python/java code is and the big part of it 
> is the proper error handling.
>
> And yes go does have panic/recover - but I never use them for the same 
> reasons I dislike exceptions. It's just really hard to reason about such 
> jumps in logic especially in massively concurrent programs that go allows us 
> to write.
>
>
>
> On Friday, July 5, 2019 at 10:30:43 PM UTC, andrey mirtchovski wrote:
>>
>> > So I was quiet on the topic then - I am not now.
>>
>> i guess you missed the point where I advocated for a new survey, well
>> advertised, where all the people who are fervent Go programmers but
>> somehow neglected to fill out the Go surveys for three years running
>> can cast their voice. "does go error handling need change: ◻️yes ◻️no
>
> --
> 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/3c8fc5c2-923f-46cd-965d-86889141dccb%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAK4xykXw4nUyiedRVKu%3DoH65w4u5qD8Cyg%2BdxuqGz2xFpBa%2BRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Jakub Labath]

But it's not a binary question.

If you ask me

Would like go to have Maybe/Option type instead of val, err - then I can 
say yes.
Would you like to have something such as Rust's Result instead of val, err 
- then I can say yes (even though I understand this may not be possible due 
to generics etc).

But what is being asked here is would you like to have error handling and 
flow of control functionality baked together - and then my answer is no.

I know from several years of experience writing both go and python/java 
that my go code is more stable than my python/java code is and the big part 
of it is the proper error handling.

And yes go does have panic/recover - but I never use them for the same 
reasons I dislike exceptions. It's just really hard to reason about such 
jumps in logic especially in massively concurrent programs that go allows 
us to write.



On Friday, July 5, 2019 at 10:30:43 PM UTC, andrey mirtchovski wrote:
>
> > So I was quiet on the topic then - I am not now. 
>
> i guess you missed the point where I advocated for a new survey, well 
> advertised, where all the people who are fervent Go programmers but 
> somehow neglected to fill out the Go surveys for three years running 
> can cast their voice. "does go error handling need change: ◻️yes ◻️no 
>

-- 
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/3c8fc5c2-923f-46cd-965d-86889141dccb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

If you’ve suffered through bad code due to exceptions, you would just be 
trading one ill for another. Exception handling when properly done is 
beautiful. Yes, a lot of people get it wrong, but they would probably get a lot 
of other things wrong as well. At least with exceptions, you have a stack trace 
- usually - :) - to help you figure out what they did wrong.

> On Jul 5, 2019, at 5:29 PM, andrey mirtchovski  wrote:
> 
>> So I was quiet on the topic then - I am not now.
> 
> i guess you missed the point where I advocated for a new survey, well
> advertised, where all the people who are fervent Go programmers but
> somehow neglected to fill out the Go surveys for three years running
> can cast their voice. "does go error handling need change: ◻️yes ◻️no
> 
> -- 
> 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/CAK4xykXEtQZKeqyC8kLoHfokySD2xDzqY91hTz9_hMX%3DdkKtQg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/5D0B862C-0778-46D9-B1A0-6A079AF125B5%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

> So I was quiet on the topic then - I am not now.

i guess you missed the point where I advocated for a new survey, well
advertised, where all the people who are fervent Go programmers but
somehow neglected to fill out the Go surveys for three years running
can cast their voice. "does go error handling need change: ◻️yes ◻️no

-- 
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/CAK4xykXEtQZKeqyC8kLoHfokySD2xDzqY91hTz9_hMX%3DdkKtQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Jakub Labath]

Sorry but how do you know we are a minority? I dislike the try proposal for 
all the reasons already mentioned by others.

I did fill out the survey but I do not remember there being an option to 
say this simple thing.

While I dislike the verbose error handling it's many times better than 
introducing flow of control constructs.

It's unusual for people to complain about the things that don't bother them.

So I was quiet on the topic then - I am not now.

Some of us had to fix so much broken java/python code with invisible and 
anonymous goto statements (aka exceptions) that even just seeing the 
keyword try prompts a physical reaction.

On Saturday, June 29, 2019 at 8:15:12 PM UTC, andrey mirtchovski wrote:
>
> > This issue seems to have resonated with a lot of people, which may be an 
> important data point when considering the try proposal 
>
> Where were all those people when the Go Surveys were being taken the 
> last few years? Overwhelmingly, the people have voted error handling 
> as a major issue. The voters may not be intimately involved with Go 
> development and may not be willing to produce proposals, but the votes 
> are there and speak loudly. A vocal minority skewing the proposals 
> with downvotes should not be a cause to abscond something that server 
> the greater good. 
>
> If the status quo can not be breached, the worst we can do is another 
> round of the Go Survey and vocally invite everyone to participate. 
>
> On Sat, Jun 29, 2019 at 2:03 PM Burak Serdar  > wrote: 
> > 
> > On Sat, Jun 29, 2019 at 1:45 PM Robert Engels  > wrote: 
> > > 
> > > If you don’t understand the history you are doomed to repeat it. The 
> ‘try’ proposal is barely better than the current  situation. There is as a 
> reason exception handling with try catch was designed along with OO. It 
> simplifies error handling immensely. “Try” as you might, you might think 
> you are improving on it, but you’re not. 
> > 
> > I think try-catch simplifies writing error handling code, but not 
> > necessarily simplifies understanding or modifying it once it is 
> > written. 
> > 
> > I, too, like the if err!=nil {} as it is. One improvement I can think 
> > of is reducing the boilerplate by implementing  a macro-like 
> > extension: 
> > 
> > func f() { 
> >   handle openErr(err) error { 
> > return err 
> >   } 
> >  x, openErr:=os.Open(...) 
> > 
> > openErr would be called if the error is non-nil. Some months ago I did 
> > write a proposal similar to this, and I was not the only one thinking 
> > along the same lines. It is backward compatible, and the code is still 
> > readable in my opinion. 
> > 
> > 
> > 
> > > 
> > > Go should implement caught exceptions and be done with it. Stop trying 
> to be cute. Take what works elsewhere and stop thinking you’re always the 
> smartest person in the room. 
> > > 
> > > On Jun 29, 2019, at 2:35 PM, Tyler Compton  > wrote: 
> > > 
> > > Sorry, forgot to CC on my last email. Here it is again: 
> > > 
> > >> And you must understand the specific: you are solving relatively hard 
> problems developing language called Go with low mistake cost and we are 
> solving simple problems with a DSL called Go but our mistake cost is much 
> higher than yours. 
> > > 
> > > 
> > > Sorry, I'm not sure I understand. Who is the "you" and "we" in these 
> circumstances? I should be clear, I'm not a Go core team member and I had 
> nothing to do with the creation of the original "try" proposal. I've just 
> been involved in the proposal and anti-proposal discussion and noticed a 
> shift in tone. 
> > > 
> > >> I thought you are trying to be as practical as possible making a 
> language with such a retarded yet somehow usable type system in XXI. But 
> this recent proposal raises some suspicions... 
> > > 
> > > 
> > > What is XXI? Are you referring to Go's type system? 
> > > 
> > > On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov <
> denis.c...@gmail.com > wrote: 
> > >> 
> > >> And prepare for wider audience in shitty “try” proposal after 1 July. 
> > >> 
> > >> -- 
> > >> 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 golan...@googlegroups.com . 
> > >> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com.
>  
>
> > >> For more options, visit https://groups.google.com/d/optout. 
> > > 
> > > -- 
> > > 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 golan...@googlegroups.com . 
> > > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
>  
>
> > > For more options, visit https://groups.google.com/d/

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Slawomir Pryczek]

It seems I'm hearing that a lot. If C++/Java is so great and go is so 
"primitive"... well what all these people are still doing in here? ;)

And i'd take "primitive" if err!=nil over exceptions any time of the day, 
at least code is streamlined, ordered and easy maintainable this way. Then 
i can even add any new code which supports error handling inside block that 
properly does error handling without looking at previous code, another 
advantage of this "primitive" approach. With go i can take anything and 
move it around almost freely. I hate try/catch both in C++ and in Java. I'm 
not even sure why we need another complex, general purpose, inconvinient 
language. If people would need all that "great" C++ stuff they could easily 
... use it? 

That's the best we can do, take decades old way of looking at things 
because it allows developers to be lazy even if it results in code which 
doesn't handle errors in optimal manner, is hard to maintain and millions 
of flies can't be wrong? All these "modern" OOP ideas are making code we 
write today so unreadable and fragmented it's impossible to write anything 
in any sane amount of time because of size of codebases we need to maintain 
nowdays. And you want to bring that craziness back?

If people are missing proven, dominant methods... i think the correct way 
is just going back to C++, D or Java. They had all of these "modern" 
"features" 10 years ago ;)


W dniu sobota, 29 czerwca 2019 22:20:47 UTC+2 użytkownik Robert Engels 
napisał:
>
> I think you are confusing with ‘doing nothing as compared to the ‘try’ 
> proposal’ with ‘do nothing’. 
>
> Go error handling is primitive at best, and people want a solution, just 
> not the ‘try’ proposal - which is the basis of my comment email - go back 
> to what is proven to work - Java and C++ are the dominant languages in use 
> today, adding their exception based error handling to Go is ‘the way to Go” 
> :) 
>
>

-- 
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/61cfc96d-92e0-46a1-8579-47324ec8e5f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Ian Lance Taylor]

On Tue, Jul 2, 2019 at 8:46 AM Space A.  wrote:
>
> May I ask, where were those surveys and how this could happen that so many 
> ppl opinions left with no attention?

The surveys were mentioned in a number of different forums, including
this mailing list.

The survey results can be found at

https://blog.golang.org/survey2016-results
https://blog.golang.org/survey2017-results
https://blog.golang.org/survey2018-results

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/CAOyqgcWbBEorLFZQQddvzYnPUu3v-vginzCtqqtprAJ4xLm7dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

['Bryan Mills' via golang-nuts]

On Monday, July 1, 2019 at 3:12:24 AM UTC-4, Ian Lance Taylor wrote:
>
> Think about how you would write a basic Go construct like 
> https://godoc.org/golang.org/x/sync/errgroup if errors are handled via 
> exceptions.  I'm not saying you can't do it--of course you can do it. 
> But it seems to me that it would require a bunch of awkward 
> boilerplate that would be easy to get wrong. 
>

That reminds me, I need to dust off CL 134395  
(the change to make `errgroup` work with things like `(*testing.T).Fatal)`).

As it turns out, we already have to deal with many of the same complexities 
that exceptions introduce, because `panic` is defined as a control-flow 
mechanism rather than an unambiguous programmer error, and is used as such 
in the `testing` and `fmt` packages (see also #28150 
).

It does indeed require a bunch of awkward boilerplate that is easy to get 
wrong. (See the `doubleDeferSandwich` function in that CL in particular.) 

-- 
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/08bc1368-0d17-4cf7-a98c-21024e146183%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Space A.]

It's so nice when someone is facing audience of thousands of users by 
"where were you"? Maybe it's because they have not too much time to read 
all these forum threads, they just use the tool instead of talking, and 
also want to leave some time for a personal life?

May I ask, where were those surveys and how this could happen that so many 
ppl opinions left with no attention? 



On Saturday, June 29, 2019 at 11:15:12 PM UTC+3, andrey mirtchovski wrote:
>
> > This issue seems to have resonated with a lot of people, which may be an 
> important data point when considering the try proposal 
>
> Where were all those people when the Go Surveys were being taken the 
> last few years?
>

-- 
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/7dda93cc-2d5e-4636-b96d-8aca26b0ebb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

Ah, wasn't aware that was how finalizers were implemented in Go. I guess the 
reason I never need to know that, is because of the Go error handling - never 
needed to use them :)




-Original Message-
>From: Ian Lance Taylor 
>Sent: Jul 1, 2019 8:46 AM
>To: Robert Engels 
>Cc: Tyler Compton , Denis Cheremisov 
>, golang-nuts 
>Subject: Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal
>
>On Mon, Jul 1, 2019 at 6:20 AM Robert Engels  wrote:
>>
>> You’ve also mentioned stack allocation without destructors again. Isn’t the 
>> proper way to handle this with defer (which in an exception based system 
>> would still run) or finalizers? Java routinely allocates on the stack using 
>> escape analysis and it is not an problem there.
>
>Finalizers don't work on stack based objects, and in Go they are
>per-object, not per-type, so you have to remember to call
>runtime.SetFinalizer.
>
>Defer statements work, but you have to remember to write them even for
>a function that has no visible way to return.
>
>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/866930349.1876.1561989871232%40wamui-cheeto.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Ian Lance Taylor]

On Mon, Jul 1, 2019 at 6:20 AM Robert Engels  wrote:
>
> You’ve also mentioned stack allocation without destructors again. Isn’t the 
> proper way to handle this with defer (which in an exception based system 
> would still run) or finalizers? Java routinely allocates on the stack using 
> escape analysis and it is not an problem there.

Finalizers don't work on stack based objects, and in Go they are
per-object, not per-type, so you have to remember to call
runtime.SetFinalizer.

Defer statements work, but you have to remember to write them even for
a function that has no visible way to return.

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/CAOyqgcWxa185Eg1UvV1_dn3GW7gxV8G3an5-uang-vBbLmd%2BDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

I meant wrapping the lower level checked exceptions n a higher level exception. 
E.g. DataInputException that wraps date date format exceptions, missing entry 
exceptions etc. Easier for higher level functions to handle these than knowing 
all of the possible low level exceptions that could be thrown. 

I’ve found a good rule to be to limit the throws clause to at most 3 
exceptions, beyond that you need to handle/wrap in a higher level exception. 

I was only using fork/join as an example. In Go you still use this design - the 
response channel carries the request and response ( or error/exception ) - at 
least that is the way I would do it. 

You’ve also mentioned stack allocation without destructors again. Isn’t the 
proper way to handle this with defer (which in an exception based system would 
still run) or finalizers? Java routinely allocates on the stack using escape 
analysis and it is not an problem there.

> On Jul 1, 2019, at 2:11 AM, Ian Lance Taylor  wrote:
> 
>> On Sun, Jun 30, 2019 at 7:34 PM robert engels  wrote:
>> 
>> I’ve developed systems that wrap checked exceptions in unchecked ones, but 
>> in every case I can think of it was to “abort to the top” - returning 
>> control (or exiting) - it is a specialized case of the re-throw, but I would 
>> argue it is rarely used in anything other than framework type code, with 
>> applications code typically wrapping the specific exception in an 
>> “higher-level application checked exception”, that the upper layers handle 
>> (possibly inspecting the “cause” exception.
> 
> Sure, but as soon as you've wrapped a checked exception you've lost
> the advantage of checked exceptions, and gone back to having to worry
> about control flow at every function call.  Which, again, is a
> significant issue in a language like Go that uses stack allocation but
> does not have destructors.
> 
> 
>> As to not answering the question about transferring across Go routines, I 
>> apologize. It was not intentional - I read the statement a few times and 
>> didn’t quite get the concern - and meant to get back to it and forgot - but 
>> I read it again a few times and still don’t understand the problem.
>> 
>> What is particular about Go that makes this difficult? It is pretty common 
>> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
>> and the worker thread throws an exception - the exception is passed to the 
>> joining thread. Conceptually, it is as if the function was called serially 
>> and the exception thrown at the fork point. In these cases the exception is 
>> wrapped, but it has to be because of the strong type system. It is also 
>> pretty trivial to declare a wrapper function that declares the checked 
>> exceptions for clarity - this is done routinely in rpc using proxies.
> 
> Go doesn't have join.
> 
> Think about how you would write a basic Go construct like
> https://godoc.org/golang.org/x/sync/errgroup if errors are handled via
> exceptions.  I'm not saying you can't do it--of course you can do it.
> But it seems to me that it would require a bunch of awkward
> boilerplate that would be easy to get wrong.
> 
> 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/CAOyqgcVN6hEJKX0F9PikVvfo2w9fT9EUD7HqOzTCmN5ce5GNNA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/F776908C-EA7F-43C0-87DA-27CE8B46855E%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

Also, I already pointed out the problems of exceptions in functional designs 
(e.g. streams), luckily and thankfully for us Go doesn’t have that concern :)


> On Jul 1, 2019, at 1:46 AM, Sanjay  wrote:
> 
> 3 of the most well-known new languages in the past decade (Swift, Rust, and 
> Go, respectively) have all eschewed exceptions for control flow in favor of 
> some sigil in the source code to propagate errors explicitly. Swift uses 
> try-statements (along with a few other control flow constructs), Rust uses 
> the "?" operator (previously the try! macro), and Go uses "if err != nil".
> 
> C++, a language which does have exceptions, has significant fractions of its 
> user base which disable exception support entirely (20% according to a 
> survey) or partially (52%). Google, for instance, almost invariably compiles 
> with -fno-exceptions and uses macros to propagate errors explicitly (see 
> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
>  to get a sense for how that works). Herb Sutter, one of the well-known 
> members of the C++ standards committee from Microsoft, has proposals out to 
> make propagating exceptions require a visible sigil in the source code (also 
> a "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an 
> interesting talk overall, I've linked to the specific relevant time). His 
> actual proposal paper is also an interesting read: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a 
> table with the following introduction "This section lays out what I believe 
> are ideal error handling characteristics. They are not unique to C++; I 
> believe they apply to most modern languages", he lists "Unhandled error 
> propagation is visible" as something not provided by C++ exceptions today.
> 
> It's possible that a decade from now, this will all have been a minor blip, 
> and you will eventually be proven right. But at the very least, this context 
> that should inform your priors.
> 
> Sanjay
> 
> PS - checked exceptions don't really have a great leg to stand on either 
> (e.g. consider their interaction with Java 8's streams: 
> https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, or 
> consider that both Scala and Kotlin don't implement support for them at all) 
> 
>> On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote:
>> I’ve developed systems that wrap checked exceptions in unchecked ones, but 
>> in every case I can think of it was to “abort to the top” - returning 
>> control (or exiting) - it is a specialized case of the re-throw, but I would 
>> argue it is rarely used in anything other than framework type code, with 
>> applications code typically wrapping the specific exception in an 
>> “higher-level application checked exception”, that the upper layers handle 
>> (possibly inspecting the “cause” exception. 
>> 
>> As to not answering the question about transferring across Go routines, I 
>> apologize. It was not intentional - I read the statement a few times and 
>> didn’t quite get the concern - and meant to get back to it and forgot - but 
>> I read it again a few times and still don’t understand the problem. 
>> 
>> What is particular about Go that makes this difficult? It is pretty common 
>> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
>> and the worker thread throws an exception - the exception is passed to the 
>> joining thread. Conceptually, it is as if the function was called serially 
>> and the exception thrown at the fork point. In these cases the exception is 
>> wrapped, but it has to be because of the strong type system. It is also 
>> pretty trivial to declare a wrapper function that declares the checked 
>> exceptions for clarity - this is done routinely in rpc using proxies. 
>> 
>> > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  wrote: 
>> > 
>> > On Sun, Jun 30, 2019 at 5:23 PM robert engels  
>> > wrote: 
>> >> 
>> >> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit 
>> >> this behavior. Addressing the points from the Joeal  article, 
>> > 
>> > Checked exceptions address some of the difficulties with exceptions. 
>> > However, they introduce new difficulties, and I do not believe they 
>> > work in large-scale programs.  In practice, checked exceptions 
>> > degenerate into unchecked exceptions.  Changing the set of exceptions 
>> > that a function throws forces all callers to adjust their set of 
>> > exceptions.  In practice this is so painful that programs catch 
>> > exceptions and turn into them into unchecked exceptions.  There are a 
>> > number of discussions on the Interwebs about the problems with checked 
>> > exceptions; here's one: https://www.artima.com/intv/handcuffs.html . 
>> > 
>> > I note that you didn't reply to my comment about passing errors across 
>> > goroutines. 
>> > 
>> > Ian 
>> > 
>> > -- 
>> > You received this message because you are subsc

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

I agree that exceptions are definitely not in vogue, but there are a lot of 
things that are which I also don’t agree with - e.g. using Python to write 
anything more than page long scripts, writing major applications in JS, etc.

As someone that lived through the C errno days, and has spent a considerable 
portion of his career being brought in to fix things, I will firmly state that 
understanding and debugging a large system is far easier when exceptions are 
used correctly. 

Maybe a happier - at least for me :) - middle ground for Go would be to treat 
errors as a specialized type internally, and then to provide stack trace and 
chain information automatically (when using try) - carrying this information in 
a side channel that could be inspected/logged when required. 

I realize that this is completely anecdotal and most likely incorrect and 
really doesn’t prove anything :) - but I did a cursory review of major projects 
in Go and Java yesterday, and the defect rates on the Go side (reported issues 
filtered by bugs) seems far greater for similar code base sizes. I have a 
feeling this Go error handling has a small part in this - errors are harder to 
track down.

> On Jul 1, 2019, at 1:46 AM, Sanjay  wrote:
> 
> 3 of the most well-known new languages in the past decade (Swift, Rust, and 
> Go, respectively) have all eschewed exceptions for control flow in favor of 
> some sigil in the source code to propagate errors explicitly. Swift uses 
> try-statements (along with a few other control flow constructs), Rust uses 
> the "?" operator (previously the try! macro), and Go uses "if err != nil".
> 
> C++, a language which does have exceptions, has significant fractions of its 
> user base which disable exception support entirely (20% according to a 
> survey) or partially (52%). Google, for instance, almost invariably compiles 
> with -fno-exceptions and uses macros to propagate errors explicitly (see 
> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
>  to get a sense for how that works). Herb Sutter, one of the well-known 
> members of the C++ standards committee from Microsoft, has proposals out to 
> make propagating exceptions require a visible sigil in the source code (also 
> a "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an 
> interesting talk overall, I've linked to the specific relevant time). His 
> actual proposal paper is also an interesting read: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a 
> table with the following introduction "This section lays out what I believe 
> are ideal error handling characteristics. They are not unique to C++; I 
> believe they apply to most modern languages", he lists "Unhandled error 
> propagation is visible" as something not provided by C++ exceptions today.
> 
> It's possible that a decade from now, this will all have been a minor blip, 
> and you will eventually be proven right. But at the very least, this context 
> that should inform your priors.
> 
> Sanjay
> 
> PS - checked exceptions don't really have a great leg to stand on either 
> (e.g. consider their interaction with Java 8's streams: 
> https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, or 
> consider that both Scala and Kotlin don't implement support for them at all) 
> 
>> On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote:
>> I’ve developed systems that wrap checked exceptions in unchecked ones, but 
>> in every case I can think of it was to “abort to the top” - returning 
>> control (or exiting) - it is a specialized case of the re-throw, but I would 
>> argue it is rarely used in anything other than framework type code, with 
>> applications code typically wrapping the specific exception in an 
>> “higher-level application checked exception”, that the upper layers handle 
>> (possibly inspecting the “cause” exception. 
>> 
>> As to not answering the question about transferring across Go routines, I 
>> apologize. It was not intentional - I read the statement a few times and 
>> didn’t quite get the concern - and meant to get back to it and forgot - but 
>> I read it again a few times and still don’t understand the problem. 
>> 
>> What is particular about Go that makes this difficult? It is pretty common 
>> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
>> and the worker thread throws an exception - the exception is passed to the 
>> joining thread. Conceptually, it is as if the function was called serially 
>> and the exception thrown at the fork point. In these cases the exception is 
>> wrapped, but it has to be because of the strong type system. It is also 
>> pretty trivial to declare a wrapper function that declares the checked 
>> exceptions for clarity - this is done routinely in rpc using proxies. 
>> 
>> > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  wrote: 
>> > 
>> > On Sun, Jun 30, 2019 at 5:23 PM rober

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Jesper Louis Andersen]

On Mon, Jul 1, 2019 at 3:43 AM Ian Lance Taylor  wrote:

>
> Checked exceptions address some of the difficulties with exceptions.
> However, they introduce new difficulties, and I do not believe they
> work in large-scale programs.


It is essentially a nominal effect system on exceptions. My bet is we are
better off it is was structural and thus automatically inferred by the
compiler. There is also the point that an exception must be a shared secret
between a raiser and a handler[0], which somewhat argues against the notion
of a checked exception in the first place.

[0]
https://existentialtype.wordpress.com/2012/12/03/exceptions-are-shared-secrets/

-- 
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/CAGrdgiXaJX4tnOUebn2FVgYGcB174OaaNsadWxdx8iMHWctZkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Jesper Louis Andersen]

On Sun, Jun 30, 2019 at 7:05 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Sun, Jun 30, 2019 at 3:19 PM Jesper Louis Andersen
>  wrote:
>
> > This is where the try-construct will definitely improve the ergonomics
> of the programming.
>
> With full respect to you opinion and/or personal preferences,
> "definitely improve" is just and only that. I _definitely_ don't share
> that opinion/personal preference.
>

I agree. That came out way too matter-of-factly.

I think it will improve ergonomics, because of the following analysis:

CON: New construct in the language means teaching and learning the language
takes more time.
CON: try(..) is a control operator. These are often harder to grasp and
rather subtle.
CON: It is sugar for a common pattern, which if written out could make code
easier to read.
PRO: It is sugar for a common pattern, which if not written out could make
code easier to read.
PRO: It will suggest a common pattern of error handling is easier to work
with in Go, thus make a stylistic choice.
PRO: It is, essentially, a typical Error monad. These are pretty common in
code and having special tooling for them tends to help.
PRO: Code is more often read then written. I think this optimizes for the
reader.
UNDECIDED: This is a pattern you also see in other languages.

My opinion, balancing those pros and cons, is that I think it ends up being
a net positive, but YMMV of course.



-- 
J.

-- 
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/CAGrdgiVSF2GRX9YpebB1OuXAv%3DDfcSvvQXyCGYAPu%3D8we7C3sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Henrik Johansson]

If it is as bad as "every sane Go shop" comes to this conclusion then I am
sure "try" will not be added...

On Mon, Jul 1, 2019 at 12:57 PM Wojciech S. Czarnecki 
wrote:

> On Mon, 1 Jul 2019 12:33:16 +0200
> Henrik Johansson  wrote:
>
> > That is one big strawman. I can live without "try" but
> > I think it would be a net gain for the language.
>
> I think it would be not. While anyone who consider 'try()' func being
> awkward
> and full of traps need not to use it in her code, everyone will have to
> cope
> with it while reading others code. Here lie dragons.
>
> 'Try()' might end as the first and topmost position on Go's "WE DON'T"
> blacklist. So it will waste Go team's time on implementing then
> maintaining,
> then every sane Go shop will forbid it.  (As it happened to C++ exceptions
> and many other C++ 'features' --  I'd seen 'we-dont' lists with over dozen
> positions).
>
> TC,
>
> --
> 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/20190701125733.4c41b9b2%40zuzia
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKOF695i%3Dnu8W2ujL6RQ_VNEQjHAjP9HAHarz5p4UnQJzNJYyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Wojciech S. Czarnecki]

On Mon, 1 Jul 2019 12:33:16 +0200
Henrik Johansson  wrote:

> That is one big strawman. I can live without "try" but
> I think it would be a net gain for the language.

I think it would be not. While anyone who consider 'try()' func being awkward
and full of traps need not to use it in her code, everyone will have to cope
with it while reading others code. Here lie dragons.

'Try()' might end as the first and topmost position on Go's "WE DON'T"
blacklist. So it will waste Go team's time on implementing then maintaining,
then every sane Go shop will forbid it.  (As it happened to C++ exceptions
and many other C++ 'features' --  I'd seen 'we-dont' lists with over dozen
positions).

TC,

-- 
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/20190701125733.4c41b9b2%40zuzia.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Henrik Johansson]

That is one big strawman. I can live without "try" but I think it would be
a net gain for the language.
Sign of the times that any discussion becomes polarized I guess...

On Mon, Jul 1, 2019 at 12:18 PM Denis Cheremisov 
wrote:

> > I think many people like the proposal but are not vocal about it.
>
> Emoji count should reflect that "silent majority" better than comments. We
> have larger negative count on `try` and overwhelming 1293 vs 154 positive
> count on leaving it as is. People who care generally dislike poorly thought
> `try`, that's it.
>
> воскресенье, 30 июня 2019 г., 15:47:54 UTC+3 пользователь
> pierr...@gmail.com написал:
>>
>> Indeed.
>>
>> I think many people like the proposal but are not vocal about it. It is
>> not perfect but it *does *bring value to the table if you read the
>> proposal in its entirety and think about how you would use/could use it in
>> a real life scenario.
>>
>> I do *decorate *errors a lot, I do care about the *control flow* (I have
>> been along time user of *defer *for error handling and find it not
>> magical or ugly but fitting beautifully with the language), which are the
>> main topics people are complaining about... And I think it actually works
>> fine in those situations.
>>
>> In fact, the try() approach has started growing on me as I write code
>> now, I feel it would help in quite a few situations and simplify, not in a
>> drastic way, but subtle and valuable one.
>>
>> My 2c.
>>
>> Le samedi 29 juin 2019 21:31:19 UTC+2, Henrik Johansson a écrit :
>>
>>> I for one like the try proposal. It removes much of my gripes with the
>>> verbosity of error handling.
>>>
>>> I think that it will become more readable than explicit error handling
>>> quite fast. Note that it is still explicit, if you don't use the try
>>> notation the error can be handled as it is now or ignored as it sometimes
>>> is now.
>>>
>>> I have a feeling that there is a quite large "silent majority" that
>>> pretty much agrees with me.
>>>
>>> On Sat, Jun 29, 2019, 21:18 Denis Cheremisov 
>>> wrote:
>>>
 And prepare for wider audience in shitty “try” proposal after 1 July.

 --
 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 golan...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
> 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/49411503-e6f1-4be7-ae39-57b55e782779%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKOF697dWwSHcNi%3DS4ErwLVpEtV%3Dem8UExnQZiLbnpwOUDrkNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Denis Cheremisov]

> I think many people like the proposal but are not vocal about it.

Emoji count should reflect that "silent majority" better than comments. We 
have larger negative count on `try` and overwhelming 1293 vs 154 positive 
count on leaving it as is. People who care generally dislike poorly thought 
`try`, that's it.

воскресенье, 30 июня 2019 г., 15:47:54 UTC+3 пользователь 
pierr...@gmail.com написал:
>
> Indeed.
>
> I think many people like the proposal but are not vocal about it. It is 
> not perfect but it *does *bring value to the table if you read the 
> proposal in its entirety and think about how you would use/could use it in 
> a real life scenario.
>
> I do *decorate *errors a lot, I do care about the *control flow* (I have 
> been along time user of *defer *for error handling and find it not 
> magical or ugly but fitting beautifully with the language), which are the 
> main topics people are complaining about... And I think it actually works 
> fine in those situations.
>
> In fact, the try() approach has started growing on me as I write code now, 
> I feel it would help in quite a few situations and simplify, not in a 
> drastic way, but subtle and valuable one.
>
> My 2c.
>
> Le samedi 29 juin 2019 21:31:19 UTC+2, Henrik Johansson a écrit :
>
>> I for one like the try proposal. It removes much of my gripes with the 
>> verbosity of error handling.
>>
>> I think that it will become more readable than explicit error handling 
>> quite fast. Note that it is still explicit, if you don't use the try 
>> notation the error can be handled as it is now or ignored as it sometimes 
>> is now.
>>
>> I have a feeling that there is a quite large "silent majority" that 
>> pretty much agrees with me.
>>
>> On Sat, Jun 29, 2019, 21:18 Denis Cheremisov  
>> wrote:
>>
>>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>>
>>> -- 
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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/49411503-e6f1-4be7-ae39-57b55e782779%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Ian Lance Taylor]

On Sun, Jun 30, 2019 at 7:34 PM robert engels  wrote:
>
> I’ve developed systems that wrap checked exceptions in unchecked ones, but in 
> every case I can think of it was to “abort to the top” - returning control 
> (or exiting) - it is a specialized case of the re-throw, but I would argue it 
> is rarely used in anything other than framework type code, with applications 
> code typically wrapping the specific exception in an “higher-level 
> application checked exception”, that the upper layers handle (possibly 
> inspecting the “cause” exception.

Sure, but as soon as you've wrapped a checked exception you've lost
the advantage of checked exceptions, and gone back to having to worry
about control flow at every function call.  Which, again, is a
significant issue in a language like Go that uses stack allocation but
does not have destructors.


> As to not answering the question about transferring across Go routines, I 
> apologize. It was not intentional - I read the statement a few times and 
> didn’t quite get the concern - and meant to get back to it and forgot - but I 
> read it again a few times and still don’t understand the problem.
>
> What is particular about Go that makes this difficult? It is pretty common 
> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
> and the worker thread throws an exception - the exception is passed to the 
> joining thread. Conceptually, it is as if the function was called serially 
> and the exception thrown at the fork point. In these cases the exception is 
> wrapped, but it has to be because of the strong type system. It is also 
> pretty trivial to declare a wrapper function that declares the checked 
> exceptions for clarity - this is done routinely in rpc using proxies.

Go doesn't have join.

Think about how you would write a basic Go construct like
https://godoc.org/golang.org/x/sync/errgroup if errors are handled via
exceptions.  I'm not saying you can't do it--of course you can do it.
But it seems to me that it would require a bunch of awkward
boilerplate that would be easy to get wrong.

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/CAOyqgcVN6hEJKX0F9PikVvfo2w9fT9EUD7HqOzTCmN5ce5GNNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Sanjay]

3 of the most well-known new languages in the past decade (Swift, Rust, and 
Go, respectively) have all eschewed exceptions for control flow in favor of 
some sigil in the source code to propagate errors explicitly. Swift uses 
try-statements (along with a few other control flow constructs), Rust uses 
the "?" operator (previously the try! macro), and Go uses "if err != nil".

C++, a language which does have exceptions, has significant fractions of 
its user base which disable exception support entirely (20% according to a 
survey) or partially (52%). Google, for instance, almost invariably 
compiles with -fno-exceptions and uses macros to propagate errors 
explicitly (see 
https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
 to 
get a sense for how that works). Herb Sutter, one of the well-known members 
of the C++ standards committee from Microsoft, has proposals out to make 
propagating exceptions require a visible sigil in the source code (also a 
"try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an 
interesting talk overall, I've linked to the specific relevant time). His 
actual proposal paper is also an interesting read: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a 
table with the following introduction "This section lays out what I believe 
are ideal error handling characteristics. They are not unique to C++; I 
believe they apply to most modern languages", he lists "Unhandled error 
propagation is visible" as something not provided by C++ exceptions today.

It's possible that a decade from now, this will all have been a minor blip, 
and you will eventually be proven right. But at the very least, this 
context that should inform your priors.

Sanjay

PS - checked exceptions don't really have a great leg to stand on either 
(e.g. consider their interaction with Java 8's streams: 
https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, 
or consider that both Scala and Kotlin don't implement support for them at 
all) 

On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote:
>
> I’ve developed systems that wrap checked exceptions in unchecked ones, but 
> in every case I can think of it was to “abort to the top” - returning 
> control (or exiting) - it is a specialized case of the re-throw, but I 
> would argue it is rarely used in anything other than framework type code, 
> with applications code typically wrapping the specific exception in an 
> “higher-level application checked exception”, that the upper layers handle 
> (possibly inspecting the “cause” exception. 
>
> As to not answering the question about transferring across Go routines, I 
> apologize. It was not intentional - I read the statement a few times and 
> didn’t quite get the concern - and meant to get back to it and forgot - but 
> I read it again a few times and still don’t understand the problem. 
>
> What is particular about Go that makes this difficult? It is pretty common 
> practice to pass exceptions across threads in Java and C++ - e.g. fork/join 
> and the worker thread throws an exception - the exception is passed to the 
> joining thread. Conceptually, it is as if the function was called serially 
> and the exception thrown at the fork point. In these cases the exception is 
> wrapped, but it has to be because of the strong type system. It is also 
> pretty trivial to declare a wrapper function that declares the checked 
> exceptions for clarity - this is done routinely in rpc using proxies. 
>
> > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  > wrote: 
> > 
> > On Sun, Jun 30, 2019 at 5:23 PM robert engels  > wrote: 
> >> 
> >> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit 
> this behavior. Addressing the points from the Joeal  article, 
> > 
> > Checked exceptions address some of the difficulties with exceptions. 
> > However, they introduce new difficulties, and I do not believe they 
> > work in large-scale programs.  In practice, checked exceptions 
> > degenerate into unchecked exceptions.  Changing the set of exceptions 
> > that a function throws forces all callers to adjust their set of 
> > exceptions.  In practice this is so painful that programs catch 
> > exceptions and turn into them into unchecked exceptions.  There are a 
> > number of discussions on the Interwebs about the problems with checked 
> > exceptions; here's one: https://www.artima.com/intv/handcuffs.html . 
> > 
> > I note that you didn't reply to my comment about passing errors across 
> > goroutines. 
> > 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWZEg091q2Z2bmNrbgewOPH-TMGnoc1hB4V44tMtGyzuw%40mail.gm

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

I’ve developed systems that wrap checked exceptions in unchecked ones, but in 
every case I can think of it was to “abort to the top” - returning control (or 
exiting) - it is a specialized case of the re-throw, but I would argue it is 
rarely used in anything other than framework type code, with applications code 
typically wrapping the specific exception in an “higher-level application 
checked exception”, that the upper layers handle (possibly inspecting the 
“cause” exception.

As to not answering the question about transferring across Go routines, I 
apologize. It was not intentional - I read the statement a few times and didn’t 
quite get the concern - and meant to get back to it and forgot - but I read it 
again a few times and still don’t understand the problem.

What is particular about Go that makes this difficult? It is pretty common 
practice to pass exceptions across threads in Java and C++ - e.g. fork/join and 
the worker thread throws an exception - the exception is passed to the joining 
thread. Conceptually, it is as if the function was called serially and the 
exception thrown at the fork point. In these cases the exception is wrapped, 
but it has to be because of the strong type system. It is also pretty trivial 
to declare a wrapper function that declares the checked exceptions for clarity 
- this is done routinely in rpc using proxies.

> On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  wrote:
> 
> On Sun, Jun 30, 2019 at 5:23 PM robert engels  wrote:
>> 
>> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this 
>> behavior. Addressing the points from the Joeal  article,
> 
> Checked exceptions address some of the difficulties with exceptions.
> However, they introduce new difficulties, and I do not believe they
> work in large-scale programs.  In practice, checked exceptions
> degenerate into unchecked exceptions.  Changing the set of exceptions
> that a function throws forces all callers to adjust their set of
> exceptions.  In practice this is so painful that programs catch
> exceptions and turn into them into unchecked exceptions.  There are a
> number of discussions on the Interwebs about the problems with checked
> exceptions; here's one: https://www.artima.com/intv/handcuffs.html .
> 
> I note that you didn't reply to my comment about passing errors across
> goroutines.
> 
> 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/CAOyqgcWZEg091q2Z2bmNrbgewOPH-TMGnoc1hB4V44tMtGyzuw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/BAD8DE0B-3A77-415D-B8D8-D376E74636B7%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Ian Lance Taylor]

On Sun, Jun 30, 2019 at 5:23 PM robert engels  wrote:
>
> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this 
> behavior. Addressing the points from the Joeal  article,

Checked exceptions address some of the difficulties with exceptions.
However, they introduce new difficulties, and I do not believe they
work in large-scale programs.  In practice, checked exceptions
degenerate into unchecked exceptions.  Changing the set of exceptions
that a function throws forces all callers to adjust their set of
exceptions.  In practice this is so painful that programs catch
exceptions and turn into them into unchecked exceptions.  There are a
number of discussions on the Interwebs about the problems with checked
exceptions; here's one: https://www.artima.com/intv/handcuffs.html .

I note that you didn't reply to my comment about passing errors across
goroutines.

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/CAOyqgcWZEg091q2Z2bmNrbgewOPH-TMGnoc1hB4V44tMtGyzuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this 
behavior. Addressing the points from the Joeal  article,

Point#1
"They are invisible in the source code. Looking at a block of code, including 
functions which may or may not throw exceptions, there is no way to see which 
exceptions might be thrown and from where. This means that even careful code 
inspection doesn’t reveal potential bugs.”

This is not true. It is a limitation of the editor. There are IDEs that will 
annotate every line with the exceptions possibly thrown by the function call - 
it is part of the function signature. The compiler will also clearly complain 
if a checked exception is not handled or re-thrown. The information is there, 
and it is certainly better than having to read documentation (which may not be 
correct) in the Go case. In the Go case, all the compiler knows is that either 
no return values or all return values must be captured (including their types), 
with nothing about possible error values, so how is the developer supposed to 
handle them - I don’t see how that is an improvement. The exception signature 
is far more powerful and self-documenting.

Point #2:

"They create too many possible exit points for a function. To write correct 
code, you really have to think about every possible code path through your 
function. Every time you call a function that can raise an exception and don’t 
catch it on the spot, you create opportunities for surprise bugs caused by 
functions that terminated abruptly, leaving data in an inconsistent state, or 
other code paths that you didn’t think about."

This is not true as well. It is common understanding when working with 
exceptions, that there are 3 typical outcomes: 1. retry 2. re-throw 3. log and 
return from function. The catch and log and continue is an anti-pattern used by 
inexperienced developers.

Granted, much of exception handling is simplified in the case of GC 
environment, and finalizers for other resources, but the latter can be too 
lazy, and thus try-with-resource which completely handles the inconsistent 
state aspect of Point #2.

Furthermore, the ‘think about every possible code path through your function” 
is pretty much nonsense. A developer does this every time they write a loop, or 
any other control structure. If anything, checked exceptions force the 
developer to think even deeper about handling errors, which a Go should be 
doing too (but can even ignore more easily).

Like I said, I think Go error handling is fine for C size applications, it 
breaks down quickly in large applications that must be resilient, mainly when 
attempting to incorporate library (internal or external code). For small 
applications developers will use if err!= nil panic(err)




> On Jun 30, 2019, at 6:09 PM, Ian Lance Taylor  wrote:
> 
> On Sun, Jun 30, 2019 at 4:16 AM robert engels  wrote:
>> 
>> I am not sure the ‘unexpected flow control’ concern is of the same 
>> importance as when this statement was first written, given paradigms like 
>> ‘reactive programming’ (I don’t like it, but it seems most others are not 
>> bothered by it).
>> 
>> I am curious more though in the belief that exceptions are unexpected flow 
>> control. At least with caught exceptions, this is not the case IMO. You know 
>> the exact point at which the exceptions can occur - this is part of the 
>> beauty of exceptions in that the code is self documenting to a higher degree 
>> and can be subject to automated analysis far more easily 
>> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go 
>> should be handled, but the compiler does not enforce this. I also think that 
>> try-with-resource solves many of the life-cycle concerns very elegantly 
>> (whether you like Java or not, a lot can be learned from the evolution the 
>> language). Still caught exceptions cause problems with functional methods 
>> (and so does error return), although I’m not a big fan of functional either 
>> (for lack of readability).
> 
> The unexpected flow of control when using exceptions is not at the
> point where the exception is thrown, nor at the point where the
> exception is caught.  It is the functions in between that point.  When
> exceptions are used routinely, every single function call is a
> possible change in flow of control.
> 
> That is of course true in Go today because any function may call
> panic, but we we can cope with that in practice because calling is
> panic is discouraged and rare, especially if an unrecovered panic
> crosses a package boundary.  But errors must be routinely returned
> across package boundaries, so if we use exceptions to handle errors
> then we inevitably have unexpected flow of control.
> 
> This is hardly a novel view, of course.  E.g.,
> https://www.joelonsoftware.com/2003/10/13/13/ .
> 
> And since Go programs routinely require transferring an error between
> one goroutine and another, in Go we would have to have to some clean
> and si

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Ian Lance Taylor]

On Sun, Jun 30, 2019 at 4:16 AM robert engels  wrote:
>
> I am not sure the ‘unexpected flow control’ concern is of the same importance 
> as when this statement was first written, given paradigms like ‘reactive 
> programming’ (I don’t like it, but it seems most others are not bothered by 
> it).
>
> I am curious more though in the belief that exceptions are unexpected flow 
> control. At least with caught exceptions, this is not the case IMO. You know 
> the exact point at which the exceptions can occur - this is part of the 
> beauty of exceptions in that the code is self documenting to a higher degree 
> and can be subject to automated analysis far more easily 
> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go should 
> be handled, but the compiler does not enforce this. I also think that 
> try-with-resource solves many of the life-cycle concerns very elegantly 
> (whether you like Java or not, a lot can be learned from the evolution the 
> language). Still caught exceptions cause problems with functional methods 
> (and so does error return), although I’m not a big fan of functional either 
> (for lack of readability).

The unexpected flow of control when using exceptions is not at the
point where the exception is thrown, nor at the point where the
exception is caught.  It is the functions in between that point.  When
exceptions are used routinely, every single function call is a
possible change in flow of control.

That is of course true in Go today because any function may call
panic, but we we can cope with that in practice because calling is
panic is discouraged and rare, especially if an unrecovered panic
crosses a package boundary.  But errors must be routinely returned
across package boundaries, so if we use exceptions to handle errors
then we inevitably have unexpected flow of control.

This is hardly a novel view, of course.  E.g.,
https://www.joelonsoftware.com/2003/10/13/13/ .

And since Go programs routinely require transferring an error between
one goroutine and another, in Go we would have to have to some clean
and simple way to transfer an exception between goroutines.

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/CAOyqgcVJiXjVbxRCidDrN7hfwiftqs280on2fuwypPphJqpC1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Jan Mercl]

On Sun, Jun 30, 2019 at 3:19 PM Jesper Louis Andersen
 wrote:

> This is where the try-construct will definitely improve the ergonomics of the 
> programming.

With full respect to you opinion and/or personal preferences,
"definitely improve" is just and only that. I _definitely_ don't share
that opinion/personal preference.

-- 
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/CAA40n-VLoDYs_PS1BQMCEmS03YfsHoXBE4vb4cmjLjto4k94pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Liam]

I wrote a proposal with function-scope named handlers that uses a per-call 
try flag and offers most features of 'catch', but it hasn't received any 
attention...
https://github.com/golang/go/issues/27519

On Saturday, June 29, 2019 at 12:45:37 PM UTC-7, Robert Engels wrote:
>
> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
> proposal is barely better than the current  situation. There is as a reason 
> exception handling with try catch was designed along with OO. It simplifies 
> error handling immensely. “Try” as you might, you might think you are 
> improving on it, but you’re not. 
>
> Go should implement caught exceptions and be done with it. Stop trying to 
> be cute. Take what works elsewhere and stop thinking you’re always the 
> smartest person in the room. 
>
>

-- 
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/7e3c1225-cc66-4bd0-b8f7-250ee5bb0e53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Michael Jones]

It seems to me that the try() mechanism could easily be undone by gofmt.
That is, if it does not work out it could be changed with low pain. This is
a virtue. Maybe the lesson is lost on some, but Go 1.0 was incompatible
with primordial Go and the Go team provided GoFix to mutate code. That was
beautiful to me. Any new idea that seems promising but could be undone
automatically if necessary is not risky.

On Sun, Jun 30, 2019 at 6:19 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Sat, Jun 29, 2019 at 9:30 PM Henrik Johansson 
> wrote:
>
>>
>> I have a feeling that there is a quite large "silent majority" that
>> pretty much agrees with me.
>>
>>
> Go is a language with the following properties, among other things:
>
> * Massive concurrency through a high amount of gorutines
> * Identity of channels, but not goroutines (goroutines don't have a Pid by
> construction, channels do have identity)
> * Shared memory space among the goroutines
>
> Such a language has a subtle property as an implication: cleanup of a
> failure must happen in the goroutine which made it. That is, error handling
> must be localized. As a result, error handling is mostly a game of treating
> it as data-flow in the program, where errors are values.
>
> There is a common case in such data flow. If an error occurs, we want to
> just return that error. This is where the try-construct will definitely
> improve the ergonomics of the programming. Go is a fairly small language.
> Certainly smaller than e.g., Javascript or Typescript. So I don't think we
> are adding that much cognitive load on people with a specialized
> construction. Of course YMMV... Haskell or OCaml programmers would just
> define a monad and call it a day, heh.
>
>
>
>
> --
> 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/CAGrdgiVU42ep%2BzJFUHc8FiZ_yQWrw2YOTCJEjMbLkyiFeC_C%3DA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@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/CALoEmQx3fY2CdaNGn41bOB50ESqxQ551HKTmeYM48o8gNscm9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Jesper Louis Andersen]

On Sat, Jun 29, 2019 at 9:30 PM Henrik Johansson 
wrote:

>
> I have a feeling that there is a quite large "silent majority" that pretty
> much agrees with me.
>
>
Go is a language with the following properties, among other things:

* Massive concurrency through a high amount of gorutines
* Identity of channels, but not goroutines (goroutines don't have a Pid by
construction, channels do have identity)
* Shared memory space among the goroutines

Such a language has a subtle property as an implication: cleanup of a
failure must happen in the goroutine which made it. That is, error handling
must be localized. As a result, error handling is mostly a game of treating
it as data-flow in the program, where errors are values.

There is a common case in such data flow. If an error occurs, we want to
just return that error. This is where the try-construct will definitely
improve the ergonomics of the programming. Go is a fairly small language.
Certainly smaller than e.g., Javascript or Typescript. So I don't think we
are adding that much cognitive load on people with a specialized
construction. Of course YMMV... Haskell or OCaml programmers would just
define a monad and call it a day, heh.

-- 
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/CAGrdgiVU42ep%2BzJFUHc8FiZ_yQWrw2YOTCJEjMbLkyiFeC_C%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[pierre . curto]

Indeed.

I think many people like the proposal but are not vocal about it. It is not 
perfect but it *does *bring value to the table if you read the proposal in 
its entirety and think about how you would use/could use it in a real life 
scenario.

I do *decorate *errors a lot, I do care about the *control flow* (I have 
been along time user of *defer *for error handling and find it not magical 
or ugly but fitting beautifully with the language), which are the main 
topics people are complaining about... And I think it actually works fine 
in those situations.

In fact, the try() approach has started growing on me as I write code now, 
I feel it would help in quite a few situations and simplify, not in a 
drastic way, but subtle and valuable one.

My 2c.

Le samedi 29 juin 2019 21:31:19 UTC+2, Henrik Johansson a écrit :

> I for one like the try proposal. It removes much of my gripes with the 
> verbosity of error handling.
>
> I think that it will become more readable than explicit error handling 
> quite fast. Note that it is still explicit, if you don't use the try 
> notation the error can be handled as it is now or ignored as it sometimes 
> is now.
>
> I have a feeling that there is a quite large "silent majority" that pretty 
> much agrees with me.
>
> On Sat, Jun 29, 2019, 21:18 Denis Cheremisov  > wrote:
>
>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/473c9666-aef5-4d25-a2fe-5832ab76eb8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

And a further example from the same blog post suggests:

ew := &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
}

This suffers from the same problem - you need to know the internals of 
errWriter to understand the flow, and certainly has unexpected flow, as an 
error in the first write causes the others to be no-ops, or does it? You need 
to both understand the flow of the API, and have the behind the scenes code 
written correctly. 

Imagine an maintainer sees this code and changes it to:

ew := &errWriter{w: fd}
ew.write(p0[a:b])
log(“this happened”);
ew.write(p1[c:d])
log(“this also happened”);
ew.write(p2[e:f])
log(“so did this”);
// and so on
if ew.err != nil {
return ew.err
}

The log is just an example of a related operation - these are possibly all very 
wrong. You might say, well you need to understand X - but this is a very simple 
example - think about it in the context of a larger more complex procedure.

Very difficult to maintain and audit IMO.

> On Jun 30, 2019, at 6:27 AM, robert engels  wrote:
> 
> Just one other important point, I think the Go documentation makes the case 
> for exceptions. If you read the blog post 
> https://blog.golang.org/errors-are-values you’ll see this suggested code 
> cited as a “better way”:
> 
> scanner := bufio.NewScanner(input)
> for scanner.Scan() {
>token := scanner.Text()
>// process token
> }
> if err := scanner.Err(); err != nil {
>// process the error
> }
> 
> so in this case, not only do you not check errors on the scanner.Scan(), you 
> have to possess deeper knowledge of the API to know that scanner.Err() needs 
> to be called (and checked) post processing.
> 
> Imagine doing code reviews of a large code base where this technique was used 
> extensively - you would need to have every internal and external API 
> memorized.
> 
> Contrast this with scanner.Scan() throwing a caught exception - it either 
> must be caught there or propagated - self documenting for the code reviewer.
> 
> 
> 
> 
>> On Jun 30, 2019, at 6:16 AM, robert engels  wrote:
>> 
>> I am not sure the ‘unexpected flow control’ concern is of the same 
>> importance as when this statement was first written, given paradigms like 
>> ‘reactive programming’ (I don’t like it, but it seems most others are not 
>> bothered by it).
>> 
>> I am curious more though in the belief that exceptions are unexpected flow 
>> control. At least with caught exceptions, this is not the case IMO. You know 
>> the exact point at which the exceptions can occur - this is part of the 
>> beauty of exceptions in that the code is self documenting to a higher degree 
>> and can be subject to automated analysis far more easily 
>> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go 
>> should be handled, but the compiler does not enforce this. I also think that 
>> try-with-resource solves many of the life-cycle concerns very elegantly 
>> (whether you like Java or not, a lot can be learned from the evolution the 
>> language). Still caught exceptions cause problems with functional methods 
>> (and so does error return), although I’m not a big fan of functional either 
>> (for lack of readability).
>> 
>> Personally, and I’ve stated it before, but I’ll go on record again, I 
>> wouldn’t change Go’s error handling at this point. I don’t think the sweet 
>> spot for Go applications requires it, and the difference in mixed code-bases 
>> would make things worse not better (e.g. exception based code calling error 
>> return based code).
>> 
>> But if I were to expand the scope, I would make breaking changes in Go2 (so 
>> no mixing of methodology) for both error handling, and generics, and 
>> probably a few other things, without regards to backwards compatibility. Go 
>> is definitely a better C, but C is a systems language, not a large scale 
>> application language. There’s a possibility that Go could be both a great 
>> systems language and a great applications language, but I’m doubtful as the 
>> concerns are too distinct.
>> 
>>> On Jun 30, 2019, at 12:05 AM, Ian Lance Taylor  wrote:
>>> 
>>> On Sat, Jun 29, 2019 at 12:45 PM Robert Engels  
>>> wrote:
 
 If you don’t understand the history you are doomed to repeat it. The ‘try’ 
 proposal is barely better than the current  situation. There is as a 
 reason exception handling with try catch was designed along with OO. It 
 simplifies error handling immensely. “Try” as you might, you might think 
 you are improving on it, but you’re not.
 
 Go should implement caught exceptions and be done with it. Stop trying to 
 be cute. Take what works elsewhere and stop thinking you’re always the 
 smartest person in the room.
>>> 
>>> I think that https://golang.org/doc/faq#exceptions is still true.
>>> 
>>> One of the commonly mentioned objections to the "try" proposal is that
>>> the try function causes a change in flow of c

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

Just one other important point, I think the Go documentation makes the case for 
exceptions. If you read the blog post https://blog.golang.org/errors-are-values 
you’ll see this suggested code cited as a “better way”:

scanner := bufio.NewScanner(input)
for scanner.Scan() {
token := scanner.Text()
// process token
}
if err := scanner.Err(); err != nil {
// process the error
}

so in this case, not only do you not check errors on the scanner.Scan(), you 
have to possess deeper knowledge of the API to know that scanner.Err() needs to 
be called (and checked) post processing.

Imagine doing code reviews of a large code base where this technique was used 
extensively - you would need to have every internal and external API memorized.

Contrast this with scanner.Scan() throwing a caught exception - it either must 
be caught there or propagated - self documenting for the code reviewer.




> On Jun 30, 2019, at 6:16 AM, robert engels  wrote:
> 
> I am not sure the ‘unexpected flow control’ concern is of the same importance 
> as when this statement was first written, given paradigms like ‘reactive 
> programming’ (I don’t like it, but it seems most others are not bothered by 
> it).
> 
> I am curious more though in the belief that exceptions are unexpected flow 
> control. At least with caught exceptions, this is not the case IMO. You know 
> the exact point at which the exceptions can occur - this is part of the 
> beauty of exceptions in that the code is self documenting to a higher degree 
> and can be subject to automated analysis far more easily 
> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go should 
> be handled, but the compiler does not enforce this. I also think that 
> try-with-resource solves many of the life-cycle concerns very elegantly 
> (whether you like Java or not, a lot can be learned from the evolution the 
> language). Still caught exceptions cause problems with functional methods 
> (and so does error return), although I’m not a big fan of functional either 
> (for lack of readability).
> 
> Personally, and I’ve stated it before, but I’ll go on record again, I 
> wouldn’t change Go’s error handling at this point. I don’t think the sweet 
> spot for Go applications requires it, and the difference in mixed code-bases 
> would make things worse not better (e.g. exception based code calling error 
> return based code).
> 
> But if I were to expand the scope, I would make breaking changes in Go2 (so 
> no mixing of methodology) for both error handling, and generics, and probably 
> a few other things, without regards to backwards compatibility. Go is 
> definitely a better C, but C is a systems language, not a large scale 
> application language. There’s a possibility that Go could be both a great 
> systems language and a great applications language, but I’m doubtful as the 
> concerns are too distinct.
> 
>> On Jun 30, 2019, at 12:05 AM, Ian Lance Taylor  wrote:
>> 
>> On Sat, Jun 29, 2019 at 12:45 PM Robert Engels  wrote:
>>> 
>>> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
>>> proposal is barely better than the current  situation. There is as a reason 
>>> exception handling with try catch was designed along with OO. It simplifies 
>>> error handling immensely. “Try” as you might, you might think you are 
>>> improving on it, but you’re not.
>>> 
>>> Go should implement caught exceptions and be done with it. Stop trying to 
>>> be cute. Take what works elsewhere and stop thinking you’re always the 
>>> smartest person in the room.
>> 
>> I think that https://golang.org/doc/faq#exceptions is still true.
>> 
>> One of the commonly mentioned objections to the "try" proposal is that
>> the try function causes a change in flow of control without clearly
>> signaling that.  In a language where exceptions are thrown to handle
>> errors, unexpected flow of control is routine.  Go does support
>> exceptions in the form of the panic and recover functions, but they
>> are stylistically discouraged, so few people use them for error
>> handling.  Experience has shown that unexpected flow of control from
>> exceptions makes it harder to write correct programs.  That is even
>> more true in a language Go which allocates objects on the stack but
>> does not have destructors.
>> 
>> 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/10DCB915-FB30-4F9A-9AFA-E36759269F94%40ix.netcom.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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...@googlegro

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

I am not sure the ‘unexpected flow control’ concern is of the same importance 
as when this statement was first written, given paradigms like ‘reactive 
programming’ (I don’t like it, but it seems most others are not bothered by it).

I am curious more though in the belief that exceptions are unexpected flow 
control. At least with caught exceptions, this is not the case IMO. You know 
the exact point at which the exceptions can occur - this is part of the beauty 
of exceptions in that the code is self documenting to a higher degree and can 
be subject to automated analysis far more easily 
(https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go should 
be handled, but the compiler does not enforce this. I also think that 
try-with-resource solves many of the life-cycle concerns very elegantly 
(whether you like Java or not, a lot can be learned from the evolution the 
language). Still caught exceptions cause problems with functional methods (and 
so does error return), although I’m not a big fan of functional either (for 
lack of readability).

Personally, and I’ve stated it before, but I’ll go on record again, I wouldn’t 
change Go’s error handling at this point. I don’t think the sweet spot for Go 
applications requires it, and the difference in mixed code-bases would make 
things worse not better (e.g. exception based code calling error return based 
code).

But if I were to expand the scope, I would make breaking changes in Go2 (so no 
mixing of methodology) for both error handling, and generics, and probably a 
few other things, without regards to backwards compatibility. Go is definitely 
a better C, but C is a systems language, not a large scale application 
language. There’s a possibility that Go could be both a great systems language 
and a great applications language, but I’m doubtful as the concerns are too 
distinct.

> On Jun 30, 2019, at 12:05 AM, Ian Lance Taylor  wrote:
> 
> On Sat, Jun 29, 2019 at 12:45 PM Robert Engels  wrote:
>> 
>> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
>> proposal is barely better than the current  situation. There is as a reason 
>> exception handling with try catch was designed along with OO. It simplifies 
>> error handling immensely. “Try” as you might, you might think you are 
>> improving on it, but you’re not.
>> 
>> Go should implement caught exceptions and be done with it. Stop trying to be 
>> cute. Take what works elsewhere and stop thinking you’re always the smartest 
>> person in the room.
> 
> I think that https://golang.org/doc/faq#exceptions is still true.
> 
> One of the commonly mentioned objections to the "try" proposal is that
> the try function causes a change in flow of control without clearly
> signaling that.  In a language where exceptions are thrown to handle
> errors, unexpected flow of control is routine.  Go does support
> exceptions in the form of the panic and recover functions, but they
> are stylistically discouraged, so few people use them for error
> handling.  Experience has shown that unexpected flow of control from
> exceptions makes it harder to write correct programs.  That is even
> more true in a language Go which allocates objects on the stack but
> does not have destructors.
> 
> 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/10DCB915-FB30-4F9A-9AFA-E36759269F94%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

ma·jor
/ˈmājər/

adjective
• 1. 
important, serious, or significant.

so I’ll apologize for my transpose, and I’ll ask it in your exact words, please 
name a significant new project in the last 2 years that wasn’t written in Java 
or C++ because it seems by your quote

> Fortunately for the mankind both C++ and Java are dying
> (no significant new projects announced for over 2 yrs afaik).

you are claiming that they are dying, and by corollary, others must not be 
(because if they all are, it is meaningless statement of comparison).

Maybe by citing these new projects that you consider significant we can better 
understand the types of projects you have in mind (in reference to my other 
email regarding focus).

> On Jun 30, 2019, at 3:38 AM, Wojciech S. Czarnecki  wrote:
> 
> On Sat, 29 Jun 2019 18:25:37 -0500
> Robert Engels  wrote:
> 
>> What exactly are you basing your incorrect opinions on? 
>> When you use terms like ‘major’ do you mean important,
>> infrastructure critical, number of users, number of developers?
>> Maybe as a frame of reference you can name a single
>> ‘major’ 
> 
> Strawman. I mentioned neither 'major' nor any other things
> you are relating to. I was precise as to the scope:
> 
>>>  no significant new projects announced for over 2 yrs afaik
> 
> Note the very word **NEW**. 
> 
>> Maybe as a frame of reference you can name a single
>> ‘major’ application that was not developed in these languages
>> that was released in the last 2 years?
> 
> What? I just said I can not name a one. I also said that what is being
> developed (maintained, enhanced) in both languages possibly will
> live for the century. At least until AI will be able to make unattended
> transpilation. 
> 
> 
> -- 
> 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/20190630103854.5be358dd%40zuzia.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/0BEB35D3-865E-447E-8B50-37CA87A7D69C%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Wojciech S. Czarnecki]

On Sat, 29 Jun 2019 22:09:10 -0700 (PDT)
Lucio  wrote:

> a lot of people have presumably realised that the consequencesof tackling
> the verbosity of the current iteration of error handling comes with a big 
> price tag.

I personally am in horror I would lose the clear sight of the flow.
Current verbosity saves hundreds of manhours even in moderate size projects.
Go's verbosity makes almost all reads strictly local and speeds up code reviews.

> Go is not just simple, it is mostly "elegant". Go2 must not be allowed to 
> become a second generation design, by democratic dictum.

The "try" problem at hand is deeper and more serious I think.
"Try" is now on the fast track because it is a brainchild of one
of Go founder fathers. 

So it is not 'by democratic dictum' per se. 'Dictum' was just an impulse, IMO.
(I'd say dictum of "the stubborn and vocal minority of fresh convertites". 
I was in this camp myself for some months, too).

Anyway I still have hope that our leading team consist of great people.

And great people, people of merit are able and willing to say
'I was wrong' when faced with real flaws in their design even
if pointed to by a dilettante stranger.

TC,

-- 
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/20190630112433.509d99fd%40zuzia.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Wojciech S. Czarnecki]

On Sat, 29 Jun 2019 18:25:37 -0500
Robert Engels  wrote:

> What exactly are you basing your incorrect opinions on? 
> When you use terms like ‘major’ do you mean important,
> infrastructure critical, number of users, number of developers?
> Maybe as a frame of reference you can name a single
> ‘major’ 

Strawman. I mentioned neither 'major' nor any other things
you are relating to. I was precise as to the scope:

>>   no significant new projects announced for over 2 yrs afaik

Note the very word **NEW**. 

> Maybe as a frame of reference you can name a single
> ‘major’ application that was not developed in these languages
> that was released in the last 2 years?

What? I just said I can not name a one. I also said that what is being
developed (maintained, enhanced) in both languages possibly will
live for the century. At least until AI will be able to make unattended
transpilation. 


-- 
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/20190630103854.5be358dd%40zuzia.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Lucio]

On Sunday, 30 June 2019 02:36:46 UTC+2, andrey mirtchovski wrote:
>
> >  I will let Andrey speak for himself. 
>
> Since this is turning into a bit of fisticuffs I will quote my private 
> message to you for clarity, here it is: 
>

Like for Brexit, I think a new survey will be surprising: a lot of people 
have presumably realised that the consequences of tackling the verbosity of 
the current iteration of error handling comes with a big price tag. That 
was, I assume, not raised in the survey, at least not clearly enough.

There is much that can be discussed here and Go has made it clear to me 
that for every correct outcome there may be far many more erroneous ones 
and that exceptions will continue to demand more code than the expected 
algorithm flow.

I agree with Daniela that breaking the rules for exceptions is going to 
hurt eventually, if not immediately. The try pseudo function, even though 
it has precedents in new and make, looks wrong. My peek into the abyss says 
we're looking at the wrong problem, it is the *return* statement that needs 
to be enhanced and I have commented, perhaps not seriously enough, in that 
respect.

Also, I have personally never used the *panic/recover* paradigm, but I 
suspect that if someone within the Go team were to write a clear exposition 
of how to use it in the rare case where it may serve as a *try/catch* 
construct, Robert (Engels) and others may well be able to offer even more 
guidance on where Go2 may be able to go to satisfy the clear necessity to 
summarise a set of errors into a single contingency handler good enough for 
the most challenged among us.

Maybe that is not possible, maybe we need to iterate in that direction, 
rather than try to make a quantum leap. But if C++ and Java are going to 
wither away, them the message "if you want X you know where to look for it" 
is going to be no longer valid for exception handling. That will put 
pressure on Go and at that point  and the outcome under pressure may be 
horrific. And, yes, I am not entirely serious about this :-).

Go is not just simple, it is mostly "elegant". Go2 must not be allowed to 
become a second generation design, by democratic dictum.


-- 
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/6ef60612-ee9b-4d34-b5b6-aade1f4db80a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Ian Lance Taylor]

On Sat, Jun 29, 2019 at 12:45 PM Robert Engels  wrote:
>
> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
> proposal is barely better than the current  situation. There is as a reason 
> exception handling with try catch was designed along with OO. It simplifies 
> error handling immensely. “Try” as you might, you might think you are 
> improving on it, but you’re not.
>
> Go should implement caught exceptions and be done with it. Stop trying to be 
> cute. Take what works elsewhere and stop thinking you’re always the smartest 
> person in the room.

I think that https://golang.org/doc/faq#exceptions is still true.

One of the commonly mentioned objections to the "try" proposal is that
the try function causes a change in flow of control without clearly
signaling that.  In a language where exceptions are thrown to handle
errors, unexpected flow of control is routine.  Go does support
exceptions in the form of the panic and recover functions, but they
are stylistically discouraged, so few people use them for error
handling.  Experience has shown that unexpected flow of control from
exceptions makes it harder to write correct programs.  That is even
more true in a language Go which allocates objects on the stack but
does not have destructors.

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/CAOyqgcWPXKi4braJ8hX2-R_mS9sS-QQm7qBpaqD%2B_Dhq1CYDMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

>  I will let Andrey speak for himself.

Since this is turning into a bit of fisticuffs I will quote my private
message to you for clarity, here it is:

--8<-
Your point is a good one. I agree with your stance.

> Which is why nothing should be done, because every proposal is going to fall 
> short of exception handling, and be little more than syntactic sugar over 
> what is available today.
>
> And Go has advantages over in many areas so stating “if you want decent error 
> handling use Java” makes my case quite nicely.
--8<-

It still means "if you want Java error handling use Java".

What was lost from my original email is that I advocate another survey
which places the question of error handling at the front and that is
more vocally popularized/disseminated (the sample set from the 2018
survey that places 5% of participants as having issues with error
handling is not a sufficiently large one, the issue and proposals
trackers are an even smaller sample set).

-- 
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/CAK4xykWarMpqcnktowpAhxXmfuZdORVVSjzVZymvLP%2BGUJOU1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

Sorry for the confusion. I did not realize I was referring to a directed 
message. I will let Andrey speak for himself.

Regardless of his response, there are numerous papers that point of the 
failures of ‘errno’ vs exceptions (although Go remediates some of that through 
the use of multiple return values).


> On Jun 29, 2019, at 7:00 PM, Dan Kortschak  wrote:
> 
> This?
> 
>> the battle you're fighting has already been lost. if you want java
>> you know where to find it :)
> 
> I don't see any indication of superiority there.
> 
> You read superiority because you believe it's superior. Not everyone
> agrees. Many see a nightmare.
> 
> On Sat, 2019-06-29 at 18:27 -0500, Robert Engels wrote:
>> It was certainly implied given the context - Java’s superior error
>> handling will not make it to Go (for a variety of reasons), so if you
>> want it, use Java. 
>> 
>> Oh, and his reply pretty much backs my analysis :)
>> 
>> 
>>> On Jun 29, 2019, at 6:25 PM, Dan Kortschak 
>>> wrote:
>>> 
>>> That's not what Andrey wrote; he said if you want java error
>>> handling
>>> us java. No where in his post was any explicit value judgement on
>>> the
>>> approach.
>>> 
 On Sat, 2019-06-29 at 15:41 -0500, Robert Engels wrote:
 And Go has advantages over in many areas so stating “if you want
 decent error handling use Java” makes my case quite nicely. 
>> 
>> 
> 

-- 
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/F070A1B1-006D-4CB7-89D8-618868951C6D%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Dan Kortschak]

This?

> the battle you're fighting has already been lost. if you want java
> you know where to find it :)

I don't see any indication of superiority there.

You read superiority because you believe it's superior. Not everyone
agrees. Many see a nightmare.

On Sat, 2019-06-29 at 18:27 -0500, Robert Engels wrote:
> It was certainly implied given the context - Java’s superior error
> handling will not make it to Go (for a variety of reasons), so if you
> want it, use Java. 
> 
> Oh, and his reply pretty much backs my analysis :)
> 
> 
> > On Jun 29, 2019, at 6:25 PM, Dan Kortschak 
> > wrote:
> > 
> > That's not what Andrey wrote; he said if you want java error
> > handling
> > us java. No where in his post was any explicit value judgement on
> > the
> > approach.
> > 
> > > On Sat, 2019-06-29 at 15:41 -0500, Robert Engels wrote:
> > > And Go has advantages over in many areas so stating “if you want
> > > decent error handling use Java” makes my case quite nicely. 
> 
> 

-- 
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/00dc3933a2164f53b24711f78261a4c12d6a4ba5.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

It was certainly implied given the context - Java’s superior error handling 
will not make it to Go (for a variety of reasons), so if you want it, use Java. 

Oh, and his reply pretty much backs my analysis :)


> On Jun 29, 2019, at 6:25 PM, Dan Kortschak  wrote:
> 
> That's not what Andrey wrote; he said if you want java error handling
> us java. No where in his post was any explicit value judgement on the
> approach.
> 
>> On Sat, 2019-06-29 at 15:41 -0500, Robert Engels wrote:
>> And Go has advantages over in many areas so stating “if you want
>> decent error handling use Java” makes my case quite nicely. 
> 

-- 
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/8681C559-C7FC-4822-A969-FEEF5A17ED0E%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

What exactly are you basing your incorrect opinions on? When you use terms like 
‘major’ do you mean important, infrastructure critical, number of users, number 
of developers? Maybe as a frame of reference you can name a single ‘major’ 
application that was not developed in these languages that was released in the 
last 2 years?

> On Jun 29, 2019, at 6:11 PM, Wojciech S. Czarnecki  wrote:
> 
> On Sat, 29 Jun 2019 15:20:11 -0500
> robert engels  wrote:
> 
>> Java and C++ are the dominant languages in use today, 
> 
> Fortunately for the mankind both C++ and Java are dying
> (no significant new projects announced for over 2 yrs afaik).
> 
> C++ had got 'feature overload' flu,
> java - legally overpriced corporate tumor.
> 
>> exception based error handling
> by someone else
> 
> (Nonetheless, code in both will live for the most of the century)
> 
> 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/20190630011132.2b864dcc%40zuzia.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/47F6D20A-DB13-4885-BB2E-BFAD71CA818E%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Dan Kortschak]

That's not what Andrey wrote; he said if you want java error handling
us java. No where in his post was any explicit value judgement on the
approach.

On Sat, 2019-06-29 at 15:41 -0500, Robert Engels wrote:
> And Go has advantages over in many areas so stating “if you want
> decent error handling use Java” makes my case quite nicely. 

-- 
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/4981b3dfab7b58b72cd31f80ceb825c2ba51ab50.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Wojciech S. Czarnecki]

On Sat, 29 Jun 2019 15:20:11 -0500
robert engels  wrote:

> Java and C++ are the dominant languages in use today, 
  
Fortunately for the mankind both C++ and Java are dying
(no significant new projects announced for over 2 yrs afaik).

C++ had got 'feature overload' flu,
java - legally overpriced corporate tumor.

> exception based error handling
by someone else

(Nonetheless, code in both will live for the most of the century)

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/20190630011132.2b864dcc%40zuzia.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Tyler Compton]

>
> I wish we had a Zen of Go and followed it.
>

You may be interested in this: https://go-proverbs.github.io/


>
> Daniela Petruzalek
> Software Engineer
> github.com/danicat
> twitter.com/danicat83
>
>
> Em sáb, 29 de jun de 2019 às 20:18, Denis Cheremisov <
> denis.cheremi...@gmail.com> escreveu:
>
>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>
>> --
>> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CA%2B%3DiygtUkrJLW1jP9f-Q-YtgkjJnSGVg6rJYW%3DD8jvrjYZwWZw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA%3DXfu0wJYeCxhSTxKotOs3XnGLx5LAWPdEFr%2BR5m2C-wd9yjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Daniela Petruzalek]

Paraphrasing the PEP 20, the Zen of Python:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.

In many ways I like to compare Go to Python, and a talk I've seen at
Gophercon 2017 from Edward Muller on Go Anti-Patterns taught me a lot about
how Go values simplicity, orthogonality and being explicit.

That said, I think the try proposal is breaking all those rules... Special
cases aren't special enough to break the rules... we don't need a different
type of error handling. Readability counts... explicit is better than
implicit...

I wish we had a Zen of Go and followed it.

Daniela Petruzalek
Software Engineer
github.com/danicat
twitter.com/danicat83


Em sáb, 29 de jun de 2019 às 20:18, Denis Cheremisov <
denis.cheremi...@gmail.com> escreveu:

> And prepare for wider audience in shitty “try” proposal after 1 July.
>
> --
> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CA%2B%3DiygtUkrJLW1jP9f-Q-YtgkjJnSGVg6rJYW%3DD8jvrjYZwWZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

Which is why nothing should be done, because every proposal is going to fall 
short of exception handling, and be little more than syntactic sugar over what 
is available today. 

And Go has advantages over in many areas so stating “if you want decent error 
handling use Java” makes my case quite nicely. 

On Jun 29, 2019, at 3:23 PM, andrey mirtchovski  wrote:

>> go back to what is proven to work - Java and C++ are the dominant languages 
>> in use today, adding their exception based error handling to Go is ‘the way 
>> to Go” :)
> 
> the battle you're fighting has already been lost. if you want java you
> know where to find it :)

-- 
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/DAC56ABD-82C5-46B7-B657-9ECBECAC345C%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

> go back to what is proven to work - Java and C++ are the dominant languages 
> in use today, adding their exception based error handling to Go is ‘the way 
> to Go” :)

the battle you're fighting has already been lost. if you want java you
know where to find it :)

-- 
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/CAK4xykVOcMaeDn8zMR%2BMbs4f%2BFS305wyLE%2BY_AQdZkcFugeMVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Burak Serdar]

On Sat, Jun 29, 2019 at 2:12 PM robert engels  wrote:
>
> I've worked heavily in 2 exception based systems (Java and C++), and in 
> neither case was exception related code a factor in maintainability. If it 
> was, it was a minor add-on to a poor design in the first place (usually lack 
> of proper encapsulation, which also leaks exceptions and their handling).
>

I didn't say it is not possible to use exceptions right. I did use
try-catch extensively as well, and they work if you do it right. The
problem is the quality deteriorates much faster when compared to
explicit error handling because tribal knowledge of how things should
be is not obvious from the maintainer's limited view of the source.

> On Jun 29, 2019, at 3:03 PM, Burak Serdar  wrote:
>
> On Sat, Jun 29, 2019 at 1:45 PM Robert Engels  wrote:
>
>
> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
> proposal is barely better than the current  situation. There is as a reason 
> exception handling with try catch was designed along with OO. It simplifies 
> error handling immensely. “Try” as you might, you might think you are 
> improving on it, but you’re not.
>
>
> I think try-catch simplifies writing error handling code, but not
> necessarily simplifies understanding or modifying it once it is
> written.
>
> I, too, like the if err!=nil {} as it is. One improvement I can think
> of is reducing the boilerplate by implementing  a macro-like
> extension:
>
> func f() {
>  handle openErr(err) error {
>return err
>  }
> x, openErr:=os.Open(...)
>
> openErr would be called if the error is non-nil. Some months ago I did
> write a proposal similar to this, and I was not the only one thinking
> along the same lines. It is backward compatible, and the code is still
> readable in my opinion.
>
>
>
>
> Go should implement caught exceptions and be done with it. Stop trying to be 
> cute. Take what works elsewhere and stop thinking you’re always the smartest 
> person in the room.
>
> On Jun 29, 2019, at 2:35 PM, Tyler Compton  wrote:
>
> Sorry, forgot to CC on my last email. Here it is again:
>
> And you must understand the specific: you are solving relatively hard 
> problems developing language called Go with low mistake cost and we are 
> solving simple problems with a DSL called Go but our mistake cost is much 
> higher than yours.
>
>
>
> Sorry, I'm not sure I understand. Who is the "you" and "we" in these 
> circumstances? I should be clear, I'm not a Go core team member and I had 
> nothing to do with the creation of the original "try" proposal. I've just 
> been involved in the proposal and anti-proposal discussion and noticed a 
> shift in tone.
>
> I thought you are trying to be as practical as possible making a language 
> with such a retarded yet somehow usable type system in XXI. But this recent 
> proposal raises some suspicions...
>
>
>
> What is XXI? Are you referring to Go's type system?
>
> On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov 
>  wrote:
>
>
> And prepare for wider audience in shitty “try” proposal after 1 July.
>
> --
> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/A4B77F76-E16F-4AE0-AAD4-29C553F079B0%40ix.netcom.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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/CAMV2RqoqxRQqF_W4sLtwivcAx7n6fn4EdEr5D4Gpz1hWbnw%3DrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

I think you are confusing with ‘doing nothing as compared to the ‘try’ 
proposal’ with ‘do nothing’.

Go error handling is primitive at best, and people want a solution, just not 
the ‘try’ proposal - which is the basis of my comment email - go back to what 
is proven to work - Java and C++ are the dominant languages in use today, 
adding their exception based error handling to Go is ‘the way to Go” :)

> On Jun 29, 2019, at 3:14 PM, andrey mirtchovski  wrote:
> 
>> This issue seems to have resonated with a lot of people, which may be an 
>> important data point when considering the try proposal
> 
> Where were all those people when the Go Surveys were being taken the
> last few years? Overwhelmingly, the people have voted error handling
> as a major issue. The voters may not be intimately involved with Go
> development and may not be willing to produce proposals, but the votes
> are there and speak loudly. A vocal minority skewing the proposals
> with downvotes should not be a cause to abscond something that server
> the greater good.
> 
> If the status quo can not be breached, the worst we can do is another
> round of the Go Survey and vocally invite everyone to participate.
> 
> On Sat, Jun 29, 2019 at 2:03 PM Burak Serdar  wrote:
>> 
>> On Sat, Jun 29, 2019 at 1:45 PM Robert Engels  wrote:
>>> 
>>> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
>>> proposal is barely better than the current  situation. There is as a reason 
>>> exception handling with try catch was designed along with OO. It simplifies 
>>> error handling immensely. “Try” as you might, you might think you are 
>>> improving on it, but you’re not.
>> 
>> I think try-catch simplifies writing error handling code, but not
>> necessarily simplifies understanding or modifying it once it is
>> written.
>> 
>> I, too, like the if err!=nil {} as it is. One improvement I can think
>> of is reducing the boilerplate by implementing  a macro-like
>> extension:
>> 
>> func f() {
>>  handle openErr(err) error {
>>return err
>>  }
>> x, openErr:=os.Open(...)
>> 
>> openErr would be called if the error is non-nil. Some months ago I did
>> write a proposal similar to this, and I was not the only one thinking
>> along the same lines. It is backward compatible, and the code is still
>> readable in my opinion.
>> 
>> 
>> 
>>> 
>>> Go should implement caught exceptions and be done with it. Stop trying to 
>>> be cute. Take what works elsewhere and stop thinking you’re always the 
>>> smartest person in the room.
>>> 
>>> On Jun 29, 2019, at 2:35 PM, Tyler Compton  wrote:
>>> 
>>> Sorry, forgot to CC on my last email. Here it is again:
>>> 
 And you must understand the specific: you are solving relatively hard 
 problems developing language called Go with low mistake cost and we are 
 solving simple problems with a DSL called Go but our mistake cost is much 
 higher than yours.
>>> 
>>> 
>>> Sorry, I'm not sure I understand. Who is the "you" and "we" in these 
>>> circumstances? I should be clear, I'm not a Go core team member and I had 
>>> nothing to do with the creation of the original "try" proposal. I've just 
>>> been involved in the proposal and anti-proposal discussion and noticed a 
>>> shift in tone.
>>> 
 I thought you are trying to be as practical as possible making a language 
 with such a retarded yet somehow usable type system in XXI. But this 
 recent proposal raises some suspicions...
>>> 
>>> 
>>> What is XXI? Are you referring to Go's type system?
>>> 
>>> On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov 
>>>  wrote:
 
 And prepare for wider audience in shitty “try” proposal after 1 July.
 
 --
 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>> 
>>> --
>>> 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/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>> 
>>> --
>>> 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

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[andrey mirtchovski]

> This issue seems to have resonated with a lot of people, which may be an 
> important data point when considering the try proposal

Where were all those people when the Go Surveys were being taken the
last few years? Overwhelmingly, the people have voted error handling
as a major issue. The voters may not be intimately involved with Go
development and may not be willing to produce proposals, but the votes
are there and speak loudly. A vocal minority skewing the proposals
with downvotes should not be a cause to abscond something that server
the greater good.

If the status quo can not be breached, the worst we can do is another
round of the Go Survey and vocally invite everyone to participate.

On Sat, Jun 29, 2019 at 2:03 PM Burak Serdar  wrote:
>
> On Sat, Jun 29, 2019 at 1:45 PM Robert Engels  wrote:
> >
> > If you don’t understand the history you are doomed to repeat it. The ‘try’ 
> > proposal is barely better than the current  situation. There is as a reason 
> > exception handling with try catch was designed along with OO. It simplifies 
> > error handling immensely. “Try” as you might, you might think you are 
> > improving on it, but you’re not.
>
> I think try-catch simplifies writing error handling code, but not
> necessarily simplifies understanding or modifying it once it is
> written.
>
> I, too, like the if err!=nil {} as it is. One improvement I can think
> of is reducing the boilerplate by implementing  a macro-like
> extension:
>
> func f() {
>   handle openErr(err) error {
> return err
>   }
>  x, openErr:=os.Open(...)
>
> openErr would be called if the error is non-nil. Some months ago I did
> write a proposal similar to this, and I was not the only one thinking
> along the same lines. It is backward compatible, and the code is still
> readable in my opinion.
>
>
>
> >
> > Go should implement caught exceptions and be done with it. Stop trying to 
> > be cute. Take what works elsewhere and stop thinking you’re always the 
> > smartest person in the room.
> >
> > On Jun 29, 2019, at 2:35 PM, Tyler Compton  wrote:
> >
> > Sorry, forgot to CC on my last email. Here it is again:
> >
> >> And you must understand the specific: you are solving relatively hard 
> >> problems developing language called Go with low mistake cost and we are 
> >> solving simple problems with a DSL called Go but our mistake cost is much 
> >> higher than yours.
> >
> >
> > Sorry, I'm not sure I understand. Who is the "you" and "we" in these 
> > circumstances? I should be clear, I'm not a Go core team member and I had 
> > nothing to do with the creation of the original "try" proposal. I've just 
> > been involved in the proposal and anti-proposal discussion and noticed a 
> > shift in tone.
> >
> >> I thought you are trying to be as practical as possible making a language 
> >> with such a retarded yet somehow usable type system in XXI. But this 
> >> recent proposal raises some suspicions...
> >
> >
> > What is XXI? Are you referring to Go's type system?
> >
> > On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov 
> >  wrote:
> >>
> >> And prepare for wider audience in shitty “try” proposal after 1 July.
> >>
> >> --
> >> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > 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/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > 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/A4B77F76-E16F-4AE0-AAD4-29C553F079B0%40ix.netcom.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/CAMV2Rqq%2BeOZoyEVj-p%3DXJE3%3DUeA%2B%2B5ZLrTLp-SdxqVhxOqec9g%40mail.gmail.com.
> For more 

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[robert engels]

I've worked heavily in 2 exception based systems (Java and C++), and in neither 
case was exception related code a factor in maintainability. If it was, it was 
a minor add-on to a poor design in the first place (usually lack of proper 
encapsulation, which also leaks exceptions and their handling).

> On Jun 29, 2019, at 3:03 PM, Burak Serdar  wrote:
> 
> On Sat, Jun 29, 2019 at 1:45 PM Robert Engels  > wrote:
>> 
>> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
>> proposal is barely better than the current  situation. There is as a reason 
>> exception handling with try catch was designed along with OO. It simplifies 
>> error handling immensely. “Try” as you might, you might think you are 
>> improving on it, but you’re not.
> 
> I think try-catch simplifies writing error handling code, but not
> necessarily simplifies understanding or modifying it once it is
> written.
> 
> I, too, like the if err!=nil {} as it is. One improvement I can think
> of is reducing the boilerplate by implementing  a macro-like
> extension:
> 
> func f() {
>  handle openErr(err) error {
>return err
>  }
> x, openErr:=os.Open(...)
> 
> openErr would be called if the error is non-nil. Some months ago I did
> write a proposal similar to this, and I was not the only one thinking
> along the same lines. It is backward compatible, and the code is still
> readable in my opinion.
> 
> 
> 
>> 
>> Go should implement caught exceptions and be done with it. Stop trying to be 
>> cute. Take what works elsewhere and stop thinking you’re always the smartest 
>> person in the room.
>> 
>> On Jun 29, 2019, at 2:35 PM, Tyler Compton  wrote:
>> 
>> Sorry, forgot to CC on my last email. Here it is again:
>> 
>>> And you must understand the specific: you are solving relatively hard 
>>> problems developing language called Go with low mistake cost and we are 
>>> solving simple problems with a DSL called Go but our mistake cost is much 
>>> higher than yours.
>> 
>> 
>> Sorry, I'm not sure I understand. Who is the "you" and "we" in these 
>> circumstances? I should be clear, I'm not a Go core team member and I had 
>> nothing to do with the creation of the original "try" proposal. I've just 
>> been involved in the proposal and anti-proposal discussion and noticed a 
>> shift in tone.
>> 
>>> I thought you are trying to be as practical as possible making a language 
>>> with such a retarded yet somehow usable type system in XXI. But this recent 
>>> proposal raises some suspicions...
>> 
>> 
>> What is XXI? Are you referring to Go's type system?
>> 
>> On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov 
>>  wrote:
>>> 
>>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>> 
>>> --
>>> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> --
>> 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/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>> 
>> --
>> 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/A4B77F76-E16F-4AE0-AAD4-29C553F079B0%40ix.netcom.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .

-- 
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/EBAF5BB3-50A2-46C0-9125-B735951A3D96%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Burak Serdar]

On Sat, Jun 29, 2019 at 1:45 PM Robert Engels  wrote:
>
> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
> proposal is barely better than the current  situation. There is as a reason 
> exception handling with try catch was designed along with OO. It simplifies 
> error handling immensely. “Try” as you might, you might think you are 
> improving on it, but you’re not.

I think try-catch simplifies writing error handling code, but not
necessarily simplifies understanding or modifying it once it is
written.

I, too, like the if err!=nil {} as it is. One improvement I can think
of is reducing the boilerplate by implementing  a macro-like
extension:

func f() {
  handle openErr(err) error {
return err
  }
 x, openErr:=os.Open(...)

openErr would be called if the error is non-nil. Some months ago I did
write a proposal similar to this, and I was not the only one thinking
along the same lines. It is backward compatible, and the code is still
readable in my opinion.



>
> Go should implement caught exceptions and be done with it. Stop trying to be 
> cute. Take what works elsewhere and stop thinking you’re always the smartest 
> person in the room.
>
> On Jun 29, 2019, at 2:35 PM, Tyler Compton  wrote:
>
> Sorry, forgot to CC on my last email. Here it is again:
>
>> And you must understand the specific: you are solving relatively hard 
>> problems developing language called Go with low mistake cost and we are 
>> solving simple problems with a DSL called Go but our mistake cost is much 
>> higher than yours.
>
>
> Sorry, I'm not sure I understand. Who is the "you" and "we" in these 
> circumstances? I should be clear, I'm not a Go core team member and I had 
> nothing to do with the creation of the original "try" proposal. I've just 
> been involved in the proposal and anti-proposal discussion and noticed a 
> shift in tone.
>
>> I thought you are trying to be as practical as possible making a language 
>> with such a retarded yet somehow usable type system in XXI. But this recent 
>> proposal raises some suspicions...
>
>
> What is XXI? Are you referring to Go's type system?
>
> On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov 
>  wrote:
>>
>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>
>> --
>> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/A4B77F76-E16F-4AE0-AAD4-29C553F079B0%40ix.netcom.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAMV2Rqq%2BeOZoyEVj-p%3DXJE3%3DUeA%2B%2B5ZLrTLp-SdxqVhxOqec9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

If you don’t understand the history you are doomed to repeat it. The ‘try’ 
proposal is barely better than the current  situation. There is as a reason 
exception handling with try catch was designed along with OO. It simplifies 
error handling immensely. “Try” as you might, you might think you are improving 
on it, but you’re not. 

Go should implement caught exceptions and be done with it. Stop trying to be 
cute. Take what works elsewhere and stop thinking you’re always the smartest 
person in the room. 

> On Jun 29, 2019, at 2:35 PM, Tyler Compton  wrote:
> 
> Sorry, forgot to CC on my last email. Here it is again:
> 
>> And you must understand the specific: you are solving relatively hard 
>> problems developing language called Go with low mistake cost and we are 
>> solving simple problems with a DSL called Go but our mistake cost is much 
>> higher than yours.
> 
> Sorry, I'm not sure I understand. Who is the "you" and "we" in these 
> circumstances? I should be clear, I'm not a Go core team member and I had 
> nothing to do with the creation of the original "try" proposal. I've just 
> been involved in the proposal and anti-proposal discussion and noticed a 
> shift in tone.
> 
>> I thought you are trying to be as practical as possible making a language 
>> with such a retarded yet somehow usable type system in XXI. But this recent 
>> proposal raises some suspicions...
> 
> What is XXI? Are you referring to Go's type system?
> 
>> On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov 
>>  wrote:
>> And prepare for wider audience in shitty “try” proposal after 1 July.
>> 
>> -- 
>> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/A4B77F76-E16F-4AE0-AAD4-29C553F079B0%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Tyler Compton]

Sorry, forgot to CC on my last email. Here it is again:

And you must understand the specific: you are solving relatively hard
> problems developing language called Go with low mistake cost and we are
> solving simple problems with a DSL called Go but our mistake cost is much
> higher than yours.
>

Sorry, I'm not sure I understand. Who is the "you" and "we" in these
circumstances? I should be clear, I'm not a Go core team member and I had
nothing to do with the creation of the original "try" proposal. I've just
been involved in the proposal and anti-proposal discussion and noticed a
shift in tone.

I thought you are trying to be as practical as possible making a language
> with such a retarded yet somehow usable type system in XXI. But this recent
> proposal raises some suspicions...
>

What is XXI? Are you referring to Go's type system?

On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov <
denis.cheremi...@gmail.com> wrote:

> And prepare for wider audience in shitty “try” proposal after 1 July.
>
> --
> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Henrik Johansson]

I for one like the try proposal. It removes much of my gripes with the
verbosity of error handling.

I think that it will become more readable than explicit error handling
quite fast. Note that it is still explicit, if you don't use the try
notation the error can be handled as it is now or ignored as it sometimes
is now.

I have a feeling that there is a quite large "silent majority" that pretty
much agrees with me.

On Sat, Jun 29, 2019, 21:18 Denis Cheremisov 
wrote:

> And prepare for wider audience in shitty “try” proposal after 1 July.
>
> --
> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAKOF6978Z_hK2g_2GFDxCzqHQxi5Eeon0N2gOx3dUYbB-TbbYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.