On Tue, Aug 1, 2023 at 10:18 AM DrGo <salah.mah...@gmail.com> wrote:
> >> 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.
>
Some of my thoughts.I can see a developer (using myself as an example)
assuming this will work in the generalized case of any non-nil return value
(not just of type error). "orelse" doesn't really convey the intent of
restricting this conditional only to the handling of errors.
What would happen if the error is ignored?
```
count, _ := io.Copy(w, r) *orelse* {
DoSomethingElse()
}
```
And does anyone besides me write code like this?
```
result, err := makeSomeNoise(); err != nil && result > 0 {
DoSomethingElse()
}
```
Would this become,
```
result, err := makeSomeNoise() orelse if result > 0 {
DoSomethingElse()
}
```
or,
```
result, err := makeSomeNoise() orelse {
if result > 0 {
DoSomethingElse()
}
}
```
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
> <https://groups.google.com/d/msgid/golang-nuts/e678eaf8-699c-4818-bbfd-92556944ccefn%40googlegroups.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/CADtPBF0O3Mm_7P026ZSyQF4Dq4cnycesh8YY9d5XugBZX_o20Q%40mail.gmail.com.
