If I look at the following example: ``` err := io.Copy(w, r) *orelse* { DoSomethingElse() } ``` This can be written usually as: ``` if io.Copy(w, r) != nil { DoSomethingElse() } ``` which is LESS boilerplate. So only for the case when there is multiple return values, there is some savings in typing.
``` result, err := makeSomeNoise() *orelse* { DoSomethingElse() } ``` vs ``` result, err := makeSomeNoise() if err != nil { DoSomethingElse() } ``` Ehm, this saves 16-9 = 7 keyboard entries. If you ask me, this still reads consistent with the "normal" way we handle errors. What happens if all of a sudden, the makeSomeNoise returns 2 errors? Then you have to undo the orelse construction, for what I understand. The more I think of this, the more I like to type those extra keyboard entries to have a clear look about what happens in the program. Just my 2 cents.... Op di 1 aug 2023 om 03:31 schreef robert engels <reng...@ix.netcom.com>: > For some perspective. Go’s error handling mimics C (for the most part). > They had a decade to decide how to improve the error handling when they > designed C++. They came up with exceptions. Java is C++ like. They had a > decade to improve error handling. They came up with exceptions + throws. > > The Go designers do not want exceptions in any way shape or form, so > you’re pretty much going to be stuck with what you have (all of the decent > proposals are “exception like”- exceptions by another name) so learn to > love it or use a different language. > > On Jul 30, 2023, at 2:02 AM, Brian Candler <b.cand...@pobox.com> wrote: > > Just to be clear: are you hard-coding the variable name "err" into the > semantics of "orelse"? That is, you can't assign the error return to a > variable of any other name? > > I disagree that this makes the job of linters any easier than it is > today. For example, if you'd written > > ... > err = io.Copy(w, r) > err = w.Close() orelse return err > } > > then you'd still need to detect "value assigned but not used" in the > linter (assuming it doesn't become *compulsory* to use "orelse" on any > assignment to a variable called "err") > > On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote: > >> I looked at the long list of proposals to improve error handling in go >> but I have not seen the one I am describing below. If I missed a similar , >> can you pls direct me to where I can find it. If not what do you think of >> this approach. >> >> This involves introducing a new keyword "orelse" that is a syntactic >> sugar for an "if err!=nil" block. >> >> The example code in Russ Cox's paper[1] will look something like this: >> >> func CopyFile(src, dst string) error { >> r, err := os.Open(src) orelse return err >> defer r.Close() >> w, err := os.Create(dst) orelse return err >> defer w.Close() >> err = io.Copy(w, r) orelse return err >> err = w.Close() orelse return err >> } >> >> It is an error to not return an error from an orelse block. >> >> In my eyes, this has the same explicitness and flexibility of the current >> style but is significantly less verbose. It permits ignoring the error, >> returning it as is or wrapping it. Because orelse is not used for any other >> purpose, it would be easy for reviewers and linters to spot lack of error >> handling. >> >> It also works well with named returns. e.g., >> >> func returnsObjorErro() (obj Obj, err error) { >> obj, err := createObj() orelse return //returns nil and err >> } >> >> otherwise orelse is like "else" so e.g., it can be followed by a block if >> additional cleanup or error formatting etc is needed before returning, eg >> w, err := os.Create(dst) orelse { >> .... >> return err >> } >> >> Similarity to "else" hopefully means that it is easy to learn. It is >> obviously backward compatible >> >> What do you think? >> >> [1] >> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md >> > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/330e88d9-8072-4614-ae56-8ce9c59517f3n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/330e88d9-8072-4614-ae56-8ce9c59517f3n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/dRLR4hxxI8A/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/60596671-D3AC-49D4-8575-F8EB3D9B6BF6%40ix.netcom.com > <https://groups.google.com/d/msgid/golang-nuts/60596671-D3AC-49D4-8575-F8EB3D9B6BF6%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CADBSaR3e2xoGg9t46RiHXmX5xHCd%2BhtdM89aydeCjWCkcfNo%2Bg%40mail.gmail.com.