FAQ
Suppose you write a function that does initialization, performs some tasks
and then does mandatory cleanup at the end. It may look like this.

func doStuffAndCleanup() error {
    doInitialization()
    defer doCleanup() // doCleanup() must run no matter what.
    if err := doStuff(); err != nil {
      return err
    }
    return doCleanup()
}

Note that doCleanup() itself may fail and return an error.
  doStuffAndCleanup() will call doCleanup() twice whenever there are no
errors. Calling doCleanup() twice is not optimal and may even break if
doCleanup() is not idempotent.

Is there any well known idiom in go for handling this sort of use case?

--
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

  • Martin Schnabel at Jul 10, 2013 at 4:50 pm

    On 07/10/2013 06:26 PM, Travis Keep wrote:
    Suppose you write a function that does initialization, performs some
    tasks and then does mandatory cleanup at the end. It may look like this.

    func doStuffAndCleanup() error {
    doInitialization()
    defer doCleanup() // doCleanup() must run no matter what.
    if err := doStuff(); err != nil {
    return err
    }
    return doCleanup()
    }

    Note that doCleanup() itself may fail and return an error.
    doStuffAndCleanup() will call doCleanup() twice whenever there are no
    errors. Calling doCleanup() twice is not optimal and may even break if
    doCleanup() is not idempotent.

    Is there any well known idiom in go for handling this sort of use case?
    you could do something tricky, but i would not call it idiomatic.
    check and assign the error in defer to a named return parameter:

          http://play.golang.org/p/ewWDWklFeE

    --
    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.
  • Travis Keep at Jul 10, 2013 at 5:02 pm
    Thanks for the advice Mike.
    On Wednesday, July 10, 2013 9:49:51 AM UTC-7, mb0 wrote:
    On 07/10/2013 06:26 PM, Travis Keep wrote:
    Suppose you write a function that does initialization, performs some
    tasks and then does mandatory cleanup at the end. It may look like this.
    func doStuffAndCleanup() error {
    doInitialization()
    defer doCleanup() // doCleanup() must run no matter what.
    if err := doStuff(); err != nil {
    return err
    }
    return doCleanup()
    }

    Note that doCleanup() itself may fail and return an error.
    doStuffAndCleanup() will call doCleanup() twice whenever there are no
    errors. Calling doCleanup() twice is not optimal and may even break if
    doCleanup() is not idempotent.

    Is there any well known idiom in go for handling this sort of use case?
    you could do something tricky, but i would not call it idiomatic.
    check and assign the error in defer to a named return parameter:

    http://play.golang.org/p/ewWDWklFeE
    --
    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
postedJul 10, '13 at 4:27p
activeJul 10, '13 at 5:02p
posts3
users2
websitegolang.org

2 users in discussion

Travis Keep: 2 posts Martin Schnabel: 1 post

People

Translate

site design / logo © 2022 Grokbase