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.
