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
>
> <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
> <mailto: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 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/60596671-D3AC-49D4-8575-F8EB3D9B6BF6%40ix.netcom.com.
