FAQ
Is defer the weak point in the Go's design?

It's very common to use defer to close files automatically before of finish
a function, but this sugar sintaxis can get the errors to be hidden, and
it's risky when you have to close several files.

I'm using the next code to defer all functions but returning the first
error found.

// * * *
var atexitFuncs []func() error

func AtExit(f func() error) {
     atexitFuncs = append(atexitFuncs, f)
}

func Exit() error {
     var e, err error
     for _, f := range atexitFuncs {
         // Only add the first error found.
         if e = f(); e != nil && err == nil {
             err = e
         }
     }
     return err
}
// * * *

Would be possible that defer can do it automatically? Run all funcions,
storing the first error found to finally return any error.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jan Mercl at Jun 14, 2013 at 10:31 am

    On Jun 14, 2013 12:19 PM, "Archos" wrote:
    Is defer the weak point in the Go's design?

    It's very common to use defer to close files automatically before of
    finish a function, but this sugar sintaxis

    It's not syntax sugar, the semantics of defer are not available by no other
    means.
    can get the errors to be hidden,
    Carelesly ignoring errors is no different in a deferred functioned or
    anywhere else.
    and it's risky when you have to close several files.
    Doesn't makes any sense to me.

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nico at Jun 14, 2013 at 10:32 am
    You could still use defer f().
    Just, define a global err and make sure that f() only updates err if err
    is nil.


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Jun 14, 2013 at 10:47 am
    forgot the list...

    2013/6/14, Rémy Oudompheng <remyoudompheng@gmail.com>:
    I don't understand what you are asking for.

    But it's easy enough to write a storeError(*error, error) function so
    that you can

    defer storeError(dest, functionThatReturnsError())

    Rémy.

    2013/6/14, Archos <raul.san@sent.com>:
    Is defer the weak point in the Go's design?

    It's very common to use defer to close files automatically before of
    finish

    a function, but this sugar sintaxis can get the errors to be hidden, and
    it's risky when you have to close several files.

    I'm using the next code to defer all functions but returning the first
    error found.

    // * * *
    var atexitFuncs []func() error

    func AtExit(f func() error) {
    atexitFuncs = append(atexitFuncs, f)
    }

    func Exit() error {
    var e, err error
    for _, f := range atexitFuncs {
    // Only add the first error found.
    if e = f(); e != nil && err == nil {
    err = e
    }
    }
    return err
    }
    // * * *

    Would be possible that defer can do it automatically? Run all funcions,
    storing the first error found to finally return any error.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chris dollin at Jun 14, 2013 at 10:51 am

    On 14 June 2013 11:19, Archos wrote:

    Is defer the weak point in the Go's design?
    It's very common to use defer to close files automatically before of finish
    a function, but this sugar sintaxis can get the errors to be hidden,

    defer isn't syntactic sugar. Syntactic sugar is about having compact
    syntax in the language for commonly-used idioms, eg have `x ++` be
    sugar for `x += 1`, and `x += 1` sugaring `px = &x; *p = *p + 1`.
    `defer is a genuine semantic feature -- you can't construct it out
    of existing bits and pieces.

    and it's risky when you have to close several files.
    >

    If the call you're deferring won't do the right thing, defer something
    that will. Note that a deferred function literal can write to named
    results:

         func example() (err error) {
             ...
             defer func() {
                 check := possiblyReturnsAnError()
                 if check != nil { err = check }
             } ()
         }

    Maybe this could justify some sugar, but I'm not convinced that
    it would happen often enough.

    Chris

    --
    Chris "allusive" Dollin

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Archos at Jun 14, 2013 at 1:54 pm
    Thanks all.

    I see that there are simple options to return the error from defer, but
    you get used to using the easiest option and finally you find in most
    of packages the usage of a simple "defer file.Close()".

    Note: The translation of "syntax sugar" is not what I was thinking.

    El viernes, 14 de junio de 2013 11:50:59 UTC+1, chris dollin escribió:
    On 14 June 2013 11:19, Archos <raul...@sent.com <javascript:>> wrote:

    Is defer the weak point in the Go's design?
    It's very common to use defer to close files automatically before of
    finish a function, but this sugar sintaxis can get the errors to be hidden,

    defer isn't syntactic sugar. Syntactic sugar is about having compact
    syntax in the language for commonly-used idioms, eg have `x ++` be
    sugar for `x += 1`, and `x += 1` sugaring `px = &x; *p = *p + 1`.
    `defer is a genuine semantic feature -- you can't construct it out
    of existing bits and pieces.

    and it's risky when you have to close several files.
    If the call you're deferring won't do the right thing, defer something
    that will. Note that a deferred function literal can write to named
    results:

    func example() (err error) {
    ...
    defer func() {
    check := possiblyReturnsAnError()
    if check != nil { err = check }
    } ()
    }

    Maybe this could justify some sugar, but I'm not convinced that
    it would happen often enough.

    Chris

    --
    Chris "allusive" Dollin
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gustavo Niemeyer at Jun 14, 2013 at 2:10 pm

    On Fri, Jun 14, 2013 at 10:54 AM, Archos wrote:
    Thanks all.

    I see that there are simple options to return the error from defer, but
    you get used to using the easiest option and finally you find in most
    of packages the usage of a simple "defer file.Close()".
    If you're reading, the error from close isn't so interesting.


    gustavo @ http://niemeyer.net

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 14, '13 at 10:19a
activeJun 14, '13 at 2:10p
posts7
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase