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

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

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

On Sat, Jun 29, 2019 at 12:45 PM Robert Engels wrote: > > If you don’t understand the history you are doomed to repeat it. The ‘try’ > proposal is barely better than the current situation. There is as a reason > exception handling with try catch was designed along with OO. It simplifies >

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

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-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

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 >

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

> 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

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

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

[go-nuts] Re: Proposal: try function constructor

Here's another demo that annotate errors with custom type. package main import ( "fmt" "io" "os" ) type Err struct { Codestring Message string Cause error } var _ error = Err{} func (e Err) Error() string { return fmt.Sprintf("[%s] %s: %s", e.Code, e.Message, e.Cause.Error()) } //

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

This? > the battle you're fighting has already been lost. if you want java > you know where to find it :) I don't see any indication of superiority there. You read superiority because you believe it's superior. Not everyone agrees. Many see a nightmare. On Sat, 2019-06-29 at 18:27 -0500,

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

It was certainly implied given the context - Java’s superior error handling will not make it to Go (for a variety of reasons), so if you want it, use Java. Oh, and his reply pretty much backs my analysis :) > On Jun 29, 2019, at 6:25 PM, Dan Kortschak wrote: > > That's not what Andrey

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

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

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

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

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

On Sat, 29 Jun 2019 15:20:11 -0500 robert engels wrote: > Java and C++ are the dominant languages in use today, Fortunately for the mankind both C++ and Java are dying (no significant new projects announced for over 2 yrs afaik). C++ had got 'feature overload' flu, java - legally overpriced

Re: [go-nuts] YAEHI (Yet another error-handling idea)

My personal thought, though it may seem strange, is that the best argument for it lies in the single word sentence at the bottom of your email. You write "Thoughts?" -- and that is very expressive in English in just the way that you mean above in your examples. I don't know enough other languages

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

> > I wish we had a Zen of Go and followed it. > You may be interested in this: https://go-proverbs.github.io/ > > Daniela Petruzalek > Software Engineer > github.com/danicat > twitter.com/danicat83 > > > Em sáb, 29 de jun de 2019 às 20:18, Denis Cheremisov < > denis.cheremi...@gmail.com>

[go-nuts] YAEHI (Yet another error-handling idea)

Hello mighty fighters of errors! Here comes my half-thought idea of another way to express error handling: *Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND an error for nil. * (Denis have shred it to pieces already in https://github.com/golang/go/issues/32852. Thank you

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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.

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

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

[go-nuts] Proposal: try function constructor

Pooof Are you serious? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit

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

And prepare for wider audience in shitty “try” proposal after 1 July. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.

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

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

[go-nuts] gorilla/websocket - Looking for a New Maintainer

I think I've posted about this before (or Gary has!), but we're looking for a new maintainer to take over the gorilla/websocket project. We've tried for a while (over a year) to find a new maintainer and haven't had any real bites. Some context: -

[go-nuts] Proposal: introduce "throws" keyword for error handling

https://github.com/golang/go/issues/32852 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on

Re: [go-nuts] What is the fundamental unit of linking in Go?

Yes, I thought about it and I am quite sure that it would be very complex code detecting referenced but unused code. I am just starting with learning how to break things apart properly. Go makes it easy to modularise but old bad habits to make monolithic stuff don't dissolve overnight, and in