Re: [go-nuts] Re: Proposal: Error handling with else catch (else keyword)

2020-02-17 Thread teknoslo
I am not obsessed with try catch, I do not even like it. And I definitely do not want to copy it or have it in Go. As I said in the post, I like to *read* else catch with an implicit try before the function call and therefore named it else catch. And I think the else catch is not like try catch

[go-nuts] Re: Proposal: Error handling with else catch (else keyword)

2020-02-17 Thread teknoslo
I do not think ternary belongs in Go. As Kevin and disroot noted below, I also prefer cleaner syntax even if it is more verbose. Its usage would also overlap with with the if statement, so which would you use when? I really appreciate the opinionated go fmt (and gofumpt) so we have do not to bot

[go-nuts] Re: Proposal: Error handling with else catch (else keyword)

2020-02-17 Thread teknoslo
Brian, you pointed out some important issues I was concerned about. Go does not and should not have any magic, so that is definitely a big problem. I also agree with you, that limiting the available expression syntax is not great and that else catch could make code non-obvious. Regarding doing

Re: [go-nuts] Re: Proposal: Error handling with else catch (else keyword)

2020-02-16 Thread MUNGAI NJOROGE
Maybe an eye opener, but why is everyone obsessed with the try..catch.. Or try..catch..else error handling? Are we trying to copy idioms from another language? The try..catch..finally in java has always played part in newbie bugs. They tend to skip the error instead of dealing with it. I prefer t

Re: [go-nuts] Re: Proposal: Error handling with else catch (else keyword)

2020-02-16 Thread disroot
Right? I’m with you here. So thankful with the custodians that prefer cleaner syntax over complex and shorter ones. On Feb 16, 2020, 15:39 -0400, Kevin Chadwick , wrote: > I prefer the clarity of the current syntax. What is the obsession with LOC. > > > I would further suggest f ?= os.os.Open("fil

Re: [go-nuts] Re: Proposal: Error handling with else catch (else keyword)

2020-02-16 Thread Kevin Chadwick
I prefer the clarity of the current syntax. What is the obsession with LOC. >I would further suggest f ?= os.os.Open("filename.ext") : >log.fatal("Cant >open filename.ext") >But the GO 'custodians' get apoplexy whenever they see any syntax that >resembles the C ternary operator. >Chill-out 'cus

[go-nuts] Re: Proposal: Error handling with else catch (else keyword)

2020-02-16 Thread lgodio2
Great suggestion f := os.Open("filename.ext") else err != nil { log.Fatal(err) } is much needed syntax improvement vs the current syntax. I would further suggest f ?= os.os.Open("filename.ext") : log.fatal("Cant open filename.ext") But the GO 'custodians' get apoplexy whenever they see an

[go-nuts] Re: Proposal: Error handling with else catch (else keyword)

2020-02-16 Thread Brian Candler
One other thing: unless you change the entire syntax of the go language, your proposed "else" modifier needs to go on the same line as the statement it relates to. For the reason see: https://golang.org/doc/faq#semicolons -- You received this message because you are subscribed to the Google Gr

[go-nuts] Re: Proposal: Error handling with else catch (else keyword)

2020-02-16 Thread Brian Candler
Code like this: f, err := os.Open("filename.ext") if err != nil{ log.Fatal(err) } would become: f := os.Open("filename.ext") else err != nil { log.Fatal(err) } The `err` variable in the example above is automatically initialized to the last return value of the function call `os.Open`.