The "leave "if err != nil" alone?" anti-proposal

[Tyler Compton]

If anyone hasn't seen it, an issue with the "proposal" tag was created earlier on the Go issue tracker titled "Proposal: leave "if err != nil" alone?" (here). This issue seems to have resonated with a lot of people, which may be an important data point when considering the try proposal, but I was surprised to see how poorly the discussion has gone. There are quite a few "me too" comments, a few image-only posts, some less than stellar personal conduct, and overall not a lot of nuanced discussion. I feel that perhaps these kinds of anti-proposals should be discouraged because they're inherently reactionary, which seems to get the discussion off on the wrong foot.

That said, this anti-proposal attracted a whole new group of Go users that I don't remember from the original try proposal discussion, which was mostly dominated by ten or twenty participants. The discussion was better, but the number of active users was much smaller. I wonder if there's a way to better engage a larger portion of the Go user base while still encouraging healthy, technical discussion.

[Denis Cheremisov]

The “try” proposal is unpopular: 246 dislikes vs 186 likes.

And aforementioned one is highly popular with more than a thousand likes and the like/dislike ration is reaching 8 (actual numbers are 1147 likes vs 148 dislikes).

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.

Now, there was an excellent example:

info := try(try(os.File(fileName)).Stat())

We are having file descriptor leak here.

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

[Denis Cheremisov]

And prepare for wider audience in shitty “try” proposal after 1 July.

[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 <denis.ch...@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...@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.

[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.ch...@gmail.com> wrote:

And prepare for wider audience in shitty “try” proposal after 1 July.

[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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.

[Burak Serdar]

On Sat, Jun 29, 2019 at 1:45 PM Robert Engels <ren...@ix.netcom.com> 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 <xav...@gmail.com> 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.ch...@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...@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...@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...@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.

[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).

[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.

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

[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” :)

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAK4xykW%2BfUE31uK4YciAh%2BhsTaUGVzi%3DPkCKN4tunYB9SocGNA%40mail.gmail.com.

[Burak Serdar]

On Sat, Jun 29, 2019 at 2:12 PM robert engels <ren...@ix.netcom.com> 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.

[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 :)

[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.

[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.ch...@gmail.com> escreveu:

And prepare for wider audience in shitty “try” proposal after 1 July.

[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.ch...@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...@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...@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.

[Wojciech S. Czarnecki]

On Sat, 29 Jun 2019 15:20:11 -0500
robert engels <ren...@ix.netcom.com> 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

[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.

[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?

> --
> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190630011132.2b864dcc%40zuzia.

[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 :)

[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.

[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).

[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).

[diogo...@gmail.com]

On Saturday, June 29, 2019 at 1:44:01 AM UTC+1, Tyler Compton wrote:

... I was surprised to see how poorly the discussion has gone. There are quite a few "me too" comments, a few image-only posts, some less than stellar personal conduct, and overall not a lot of nuanced discussion. I feel that perhaps these kinds of anti-proposals should be discouraged because they're inherently reactionary, which seems to get the discussion off on the wrong foot.

I agree with you. Maybe that's not what the author intended, but to me that anti-proposal feels like a giant middle finger to everyone - myself included - who feels unhappy with the current state of Go error handling. I think the quality of that discussion really just reflects its non-constructive nature.

At risk of stating the obvious, I think we're being badly bitten by the bikeshed effect here; the subject under discussion is relatively easy to grasp, and so we get a litany of both counter-proposals (which has even happened before - see proposal: Go 2: simplify error handling with || err suffix) and zealously-held opinions.

I also must say that I feel dismayed by how negative the tone of the conversation around the `try` proposal has been. I would certainly not expect everyone to like it as much as I do, but some people seem frightened or affronted by it far beyond what I'd consider reasonable.

[robert engels]

I think the hostility stems from the fact that there are two very distinct camps (sort of mirrors the current political world). There are those that think the current Go way is fine, and no need to fix it. There are others that think it needs to be radically overhauled (and that ‘try’ doesn’t go far enough) - so neither camp is happy, and maybe both feel that the change is an appeasement and maybe ‘change for change sake’/marketability, and that’s bound to make both sides (with strong beliefs as you state) kind of frustrated and maybe angry.

People don’t like change, and they don’t like compromise while it is happening, but they often realize it was the best course of action at a later date.

Although I agree with you that the subject is easy to grasp, I don’t think that necessarily makes the solution easy. What is “best” heavily depends on the use-case, and with a general purpose language, you end up with conflicting “bests”. Which is why I’ve argued for quite a while that for Go to truly succeed, it needs to define what it is primarily used for, and then the language constructs and facilities can align. A lot of the complaints around Java is that it has become so large (and complex) - and the reason being it tries to be all things to all people. Often the hardest thing to do when designing software is to know what to leave out, and I think the Go elders have done a admirable job here. It is the community, mainly the developers that have invested time/effort in learning & championing Go, that want to expand its area of influence (and complexity) - not coincidentally increasing their value at the same time.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7573beb9-9c85-461d-9c3d-96b73b891c8b%40googlegroups.com.

[Ian Lance Taylor]

On Sat, Jun 29, 2019 at 12:45 PM Robert Engels <ren...@ix.netcom.com> 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

[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.

[Wojciech S. Czarnecki]

On Sat, 29 Jun 2019 18:25:37 -0500
Robert Engels <ren...@ix.netcom.com> 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

[Wojciech S. Czarnecki]

On Sat, 29 Jun 2019 22:09:10 -0700 (PDT)
Lucio <lucio...@gmail.com> 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,

[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).

-- 
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+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190630103854.5be358dd%40zuzia.

[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.

[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.

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

[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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/52010C3B-2719-450D-8FD7-33AC6E3457CC%40ix.netcom.com.

[pierre...@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 <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.

[Jesper Louis Andersen]

On Sat, Jun 29, 2019 at 9:30 PM Henrik Johansson <dahan...@gmail.com> 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.

[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. 

--
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...@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. Jones
michae...@gmail.com

[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

[Zach Jeyakaran]

If good Go code handles or wraps every error, that code would never use 'try'. It seems weird to add a language feature that many codebases would discourage the use of.

[Jan Mercl]

On Sun, Jun 30, 2019 at 3:19 PM Jesper Louis Andersen
<jesper.lou...@gmail.com> 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.

[Ian Lance Taylor]

On Sun, Jun 30, 2019 at 4:16 AM robert engels <ren...@ix.netcom.com> 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

[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)

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVJiXjVbxRCidDrN7hfwiftqs280on2fuwypPphJqpC1g%40mail.gmail.com.

[Ian Lance Taylor]

On Sun, Jun 30, 2019 at 5:23 PM robert engels <ren...@ix.netcom.com> 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

[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.

> --
> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWZEg091q2Z2bmNrbgewOPH-TMGnoc1hB4V44tMtGyzuw%40mail.gmail.com.

[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) 

> To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Ian Lance Taylor]

On Sun, Jun 30, 2019 at 7:34 PM robert engels <ren...@ix.netcom.com> 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

[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 написал:

[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...

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@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.

[Wojciech S. Czarnecki]

On Mon, 1 Jul 2019 12:33:16 +0200
Henrik Johansson <dahan...@gmail.com> 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,

[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...

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190701125733.4c41b9b2%40zuzia.

[Jesper Louis Andersen]

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.

[Jesper Louis Andersen]

On Mon, Jul 1, 2019 at 3:43 AM Ian Lance Taylor <ia...@golang.org> 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/

[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.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3ac00e65-7476-40b5-8328-3aef547e0541%40googlegroups.com.

[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 <balas...@gmail.com> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3ac00e65-7476-40b5-8328-3aef547e0541%40googlegroups.com.

[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.

> --
> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVN6hEJKX0F9PikVvfo2w9fT9EUD7HqOzTCmN5ce5GNNA%40mail.gmail.com.

[Ian Lance Taylor]

On Mon, Jul 1, 2019 at 6:20 AM Robert Engels <ren...@ix.netcom.com> 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

[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 :)

[David Suarez]

The number of posts on this topic piqued my curiosity so I hope to add some considerations after doing some research on this trail that I hope you find useful.

TL;DR:  It is possible that the reason for the interest in improving "exception handling" in the proposed way is driven by individuals that are not yet fully comfortable in the language

From what I have gathered, the reason for improving this area was due to a Go Survey.  This reminds me of this popular quote:

Quote. “If I had asked people what they wanted, they would have said faster horses.”  Henry Ford, Innovation, 

Please note that while I did not participate in the survey, I would probably have said the same thing until I got "used to it".  The interesting support bit from the survey was the answer to, "I have used Go for..."  -  suggests that 1/3rd of the respondents have only 1 year experience or less with the language and a full half have less than 2 years experience. In my experience, when I started Go I was (and still am in some cases) using some Java paradigms in them that make sense to me which is great for transition but may not be great for the language long run

I am sure folks that have been around a while would agree that some of the reasons they are considering or actively changing languages tend to be due to bloat and unnecessary features that eventually weigh down productivity because there are 10 ways to skin the cat and everyone has a different opinion due to either how the rest of the code base does it or what is new.  

The large response to this thread suggests that potentially there may be a better feature out there that merits some attention and I would suggest it may be something that should come from the 2+ years experience crowd (if weighting of the results is possible) as those are likely the challenges that newbies like me will eventually encounter.  Weighing the survey results by experience may help Go stay ahead of the curve.  Just my .02

**  Side note:  I am a relative newcomer to Go (~8-9 months) so there is likely some bias there from my newness.  Add salt here....

On Friday, June 28, 2019 at 7:44:01 PM UTC-5, Tyler Compton wrote:

If anyone hasn't seen it, an issue with the "proposal" tag was created earlier on the Go issue tracker titled "Proposal: leave "if err != nil" alone?" (here). This issue seems to have resonated with a lot of people, which may be an important data point when considering the try proposal, but I was surprised to see how poorly the discussion has gone. There are quite a few "me too" comments, a few image-only posts, some less than stellar personal conduct, and overall not a lot of nuanced discussion. I feel that perhaps these kinds of anti-proposals should be discouraged because they're inherently reactionary, which seems to get the discussion off on the wrong foot.

That said, this anti-proposal attracted a whole new group of Go users that I don't remember from the original try proposal discussion, which was mostly dominated by ten or twenty participants. The discussion was better, but the number of active users was much smaller. I wonder if there's a way to better engage a larger portion of the Go user base while still encouraging healthy, technical discussion.

[Robert Engels]

I think that is going to suffer greatly from sampling bias.

You may have an engineer with 20+ years of programming in a variety of languages - using both exceptions, and error values, and be new to Go, but still have substantial insight as to the relative merits and drawbacks of proposed options.

In fact, I would argue that it is these experienced engineers that can foretell the "end result" of various paths with far greater accuracy than a new developer with multiple years of nothing but Go experience.

Nothing is new, it is an impedance matching exercise.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1284af52-5fd6-4cd0-9bd3-cc69fd1c2fc7%40googlegroups.com.

[Henrik Johansson]

This is funny since you are perfectly describing the Go core team... ;)

I really can't get my head around it that this topic generates so much vitriol (maybe harsh).

Generics I kinda get but this is just incredible.

Don't like try? Don't use it.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/974016176.5469.1561999325924%40wamui-cheeto.atl.sa.earthlink.net.

[Robert Engels]

I don't think that has anything to do with what I said.

I stated that experienced developers with minimal Go experience can probably offer deeper insights than new developers with only Go experience.

The Go team is experienced developers (at least the ones I know), AND have deep Go experience (I am assuming - but maybe not on the Go application vs internal development side).

If you are making the claim that the Go team "knows all", then why even have these conversations in the first place? Why have any community involvement at all? I am pretty sure this is not the position of the "Go team".

[Henrik Johansson]

I am not making this argument but you are continuously referring to experienced developer's preferences (perhaps someone else more if so I am sorry).

Don't get me wrong. Experience is good and weigh a lot especially combined with education and wits. Perhaps we can both concede that there are such developers in both camps.

[Robert Engels]

I never disputed that there were (in both camps). I disputed the original argument that preferring the input of people with extensive Go experience, over minimal Go experience was a valid approach, and argued that approach was short-sighted and error prone (for the reasons cited).

Not to fan any unrelated flames, but I would rank experience > wits > education. Ideally you have an abundance of all three, but only the first and last have a time component (and by experience I am referring to expert experience, as in an 'expert plumber'), but its also very hard to get the first, without the other two.

[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?

[Bryan Mills]

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.) 

[Ian Lance Taylor]

On Tue, Jul 2, 2019 at 8:46 AM Space A. <reexi...@gmail.com> 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

[Dave Cohen]

On Friday, June 28, 2019 at 5:44:01 PM UTC-7, Tyler Compton wrote:

If anyone hasn't seen it, an issue with the "proposal" tag was created earlier on the Go issue tracker titled "Proposal: leave "if err != nil" alone?" (here). This issue seems to have resonated with a lot of people, which may be an important data point when considering the try proposal, but I was surprised to see how poorly the discussion has gone. There are quite a few "me too" comments, a few image-only posts, some less than stellar personal conduct, and overall not a lot of nuanced discussion. I feel that perhaps these kinds of anti-proposals should be discouraged because they're inherently reactionary, which seems to get the discussion off on the wrong foot.

That said, this anti-proposal attracted a whole new group of Go users that I don't remember from the original try proposal discussion, which was mostly dominated by ten or twenty participants. The discussion was better, but the number of active users was much smaller. I wonder if there's a way to better engage a larger portion of the Go user base while still encouraging healthy, technical discussion.

I've noticed that `go fmt` generally format funcs into multiple lines, but does allow one-liners. That is, it will leave a function like this as just one line:

func statusUpdate() string { return "" }

 

(For more examples, grep "{ return" in the standard library.)

While I know that "one line if statements" have been discussed and over-discussed, I'll go out on a limb and suggest maybe `go fmt` should allow a "one line if" in one circumstance...are you ready for it?.... when the then clause contains only a `return ...`.

This means the following would be allowed by `go fmt`...

    if err != nil { return err }

or

    if err != nil { return fmt.Errorf("I like to wrap my errors: %s", err) }

This makes error handling more concise, by some lines, in those cases handled by the `try` proposal.  And also more concise while allowing wrapping or testing for error values other than nil.

It's a modest proposal in that it only saves lines of code.  It requires no language changes, just `go fmt` changes. This would be analogous to what `go fmt` already allows in one line funcs, and in my opinion would not negatively affect readability.  If enough folks here reach out to me supporting this idea, I'd submit a proper proposal.

[Russtopia]

Score one in support for this, from the "peanut gallery" of "experienced programmers in other languages, but only around 2 years of Go". I thought at first that if err != nil { ... } seemed clumsy, but I myself don't like exceptions and implicit flow control constructs much and the more I used Go, the more natural it felt. If anything, a way to pretty-print stack traces would be the main thing I'd like to more quickly parse failure paths, though I have seen at least one project already that does this so it needn't be a core part of the language.

A gofmt one-line with return style as described here seems like a very nice balance to me.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/42b8fc5d-2f0a-4951-8ca5-0476e23fd4a7%40googlegroups.com.

[Jon Conradt]

I have been following the various proposals for changing error handling in Go since the beginning. Recently I've decided I probably would not use them and I would stick with the explicit error checking. While verbose and repetitive, in my opinion it is the easiest to read and understand.

I've begun to wonder why the language should be changed when we could just make it easy for editors to anticipate the need for the boilerplate and provide it. Others have mentioned macros, and for me that solves the repetition and keyboarding issues.

My vote is to not change the language, but to change the editors (or even gofmt).

Jon

[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” :)

[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 <bse...@ieee.org> wrote:
>
> On Sat, Jun 29, 2019 at 1:45 PM Robert Engels <ren...@ix.netcom.com> 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 <xav...@gmail.com> 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/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/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 golan...@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.

[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

[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.

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAK4xykXEtQZKeqyC8kLoHfokySD2xDzqY91hTz9_hMX%3DdkKtQg%40mail.gmail.com.

[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.

[andrey mirtchovski]

- Other: [ ]

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

[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 <mirtc...@gmail.com> 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.

[Lucio De Re]

On 7/6/19, Jakub Labath <jla...@labath.ca> 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.

[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.

[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 :-)

[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. 

[Wojciech S. Czarnecki]

On Tue, 9 Jul 2019 02:26:03 -0700 (PDT)
Nicolas Grilly <nic...@vocationcity.com> 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

[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?

[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.

[Nicolas Grilly]

On Tue, Jul 9, 2019 at 4:44 PM Space A. <reexi...@gmail.com> 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 :-)

[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 <ia...@golang.org> wrote:
>
> On Sun, Jun 30, 2019 at 5:23 PM robert engels <ren...@ix.netcom.com> 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.gmail.com.

[Sam Whited]

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

[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.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20e08321-1c95-4663-a94e-604f62f838ac%40googlegroups.com.

[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

[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

[roger peppe]

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

[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

[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, <s...@samwhited.com> 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.

[Dan Kortschak]

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