>> What happens if all of a sudden, the makeSomeNoise returns 2 errors? Then
you have to undo the orelse construction, for what I understand.
No as long as both errors are meant to be handled as errors. Orelse will be
triggered if any or both were not nil.
On Tuesday, August 1, 2023 at 1:36:04 AM UTC-6 Marcello H wrote:
> 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 <ren...@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.ca...@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...@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...@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/e678eaf8-699c-4818-bbfd-92556944ccefn%40googlegroups.com.
