FAQ
The language specification seems silent on what is returned from a defer'd
function. The current implementation appears to just return nil, making it
difficult to determine the true outcome of the defer'd function.

Is this correct?

Will defer'd functions always return nil? That is, is there any thought to
allowing defer to return real values in later versions of Go?

Meanwhile, is there any alternative to handling this case other than
isolating panics from opens in separate functions?

func handleWork() {
...
data, err := doWork()
if err != nil { handleProblem(data); }
if data == nil { return; }
processData(data)
...
}

func doWork() ([]byte, error) {

defer func() ([]byte, error) {
if err := recover(); err != nil {
return myDefault, myError // should not return nil, nil
}
return closeResources() // can validly return nil, nil
}
...
openResources()
...
panicingFunction()
}

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

  • Roger peppe at Mar 18, 2013 at 5:39 pm

    On 18 March 2013 17:36, Gbr wrote:
    The language specification seems silent on what is returned from a defer'd
    function. The current implementation appears to just return nil, making it
    difficult to determine the true outcome of the defer'd function.

    Is this correct?

    Will defer'd functions always return nil? That is, is there any thought to
    allowing defer to return real values in later versions of Go?

    Meanwhile, is there any alternative to handling this case other than
    isolating panics from opens in separate functions?

    func handleWork() {
    ...
    data, err := doWork()
    if err != nil { handleProblem(data); }
    if data == nil { return; }
    processData(data)
    ...
    }

    func doWork() ([]byte, error) {

    defer func() ([]byte, error) {
    if err := recover(); err != nil {
    return myDefault, myError // should not return nil, nil
    }
    return closeResources() // can validly return nil, nil
    }
    you can assign to named return values in a return.

    func doWork() (data []byte, err error) {
    defer func() {
    if rerr := recover(); rerr != nil {
    data, err = myDefault, rerr
    }
    }()
    something()
    }

    --
    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.
  • Nate Finch at Mar 18, 2013 at 6:14 pm

    On Monday, March 18, 2013 1:39:00 PM UTC-4, rog wrote:
    you can assign to named return values in a return.

    func doWork() (data []byte, err error) {
    defer func() {
    if rerr := recover(); rerr != nil {
    data, err = myDefault, rerr
    }
    }()
    something()
    }
    To expand on this - you very often should be deferring a closure (like rog
    is above), and thus can assign to variables that are accessible from inside
    the function, including named return values.

    --
    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.
  • Ian Lance Taylor at Mar 18, 2013 at 8:29 pm

    On Mon, Mar 18, 2013 at 10:39 AM, roger peppe wrote:
    On 18 March 2013 17:36, Gbr wrote:
    The language specification seems silent on what is returned from a defer'd
    function. The current implementation appears to just return nil, making it
    difficult to determine the true outcome of the defer'd function.

    Is this correct?

    Will defer'd functions always return nil? That is, is there any thought to
    allowing defer to return real values in later versions of Go?

    Meanwhile, is there any alternative to handling this case other than
    isolating panics from opens in separate functions?

    func handleWork() {
    ...
    data, err := doWork()
    if err != nil { handleProblem(data); }
    if data == nil { return; }
    processData(data)
    ...
    }

    func doWork() ([]byte, error) {

    defer func() ([]byte, error) {
    if err := recover(); err != nil {
    return myDefault, myError // should not return nil, nil
    }
    return closeResources() // can validly return nil, nil
    }
    you can assign to named return values in a return.

    func doWork() (data []byte, err error) {
    defer func() {
    if rerr := recover(); rerr != nil {
    data, err = myDefault, rerr
    }
    }()
    something()
    }

    And, to be clear, the return values of the deferred function, if any,
    are ignored.

    Ian

    --
    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.
  • Gbr at Mar 19, 2013 at 6:36 am
    Got it. Thanks to all for the help!

    Gerald
    On Monday, March 18, 2013 1:29:42 PM UTC-7, Ian Lance Taylor wrote:
    On Mon, Mar 18, 2013 at 10:39 AM, roger peppe wrote:
    On 18 March 2013 17:36, Gbr <gbrose...@gmail.com <javascript:>> wrote:
    The language specification seems silent on what is returned from a
    defer'd
    function. The current implementation appears to just return nil,
    making it
    difficult to determine the true outcome of the defer'd function.

    Is this correct?

    Will defer'd functions always return nil? That is, is there any
    thought to
    allowing defer to return real values in later versions of Go?

    Meanwhile, is there any alternative to handling this case other than
    isolating panics from opens in separate functions?

    func handleWork() {
    ...
    data, err := doWork()
    if err != nil { handleProblem(data); }
    if data == nil { return; }
    processData(data)
    ...
    }

    func doWork() ([]byte, error) {

    defer func() ([]byte, error) {
    if err := recover(); err != nil {
    return myDefault, myError // should not return nil, nil
    }
    return closeResources() // can validly return nil, nil
    }
    you can assign to named return values in a return.

    func doWork() (data []byte, err error) {
    defer func() {
    if rerr := recover(); rerr != nil {
    data, err = myDefault, rerr
    }
    }()
    something()
    }

    And, to be clear, the return values of the deferred function, if any,
    are ignored.

    Ian
    --
    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
postedMar 18, '13 at 5:36p
activeMar 19, '13 at 6:36a
posts5
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase