FAQ
It struck me that someone may have already brought this up and there may be
interesting reasons to shoot it down: would it make sense to extend new()
and make() to return an optional error code on failure? Like

p, err := new(int)

or

v, err := make([]int, 10)

This is obviously modelled on the "comma OK" idiom for multiples.

Feel free to point me to previous discussions...

Lucio.

PS: I note that in general the ", err" part right now is nor optional and
much discussion about error detection suggests that it is better so. But
in this case of built-in functionality, it may be preferable to have the
construct with its optionality than to reject the construct because its
syntax would be inconsistent. Just my opinion, of course.

--

Search Discussions

  • Dave Cheney at Nov 29, 2012 at 6:36 am
    What error condition would new/make report ?
    On Thu, Nov 29, 2012 at 5:31 PM, Lucio wrote:
    It struck me that someone may have already brought this up and there may be
    interesting reasons to shoot it down: would it make sense to extend new()
    and make() to return an optional error code on failure? Like

    p, err := new(int)

    or

    v, err := make([]int, 10)

    This is obviously modelled on the "comma OK" idiom for multiples.

    Feel free to point me to previous discussions...

    Lucio.

    PS: I note that in general the ", err" part right now is nor optional and
    much discussion about error detection suggests that it is better so. But in
    this case of built-in functionality, it may be preferable to have the
    construct with its optionality than to reject the construct because its
    syntax would be inconsistent. Just my opinion, of course.

    --
    --
  • Ian Lance Taylor at Nov 29, 2012 at 6:49 am

    On Wed, Nov 28, 2012 at 10:31 PM, Lucio wrote:
    It struck me that someone may have already brought this up and there may be
    interesting reasons to shoot it down: would it make sense to extend new()
    and make() to return an optional error code on failure?
    There are various times when Go will implicitly allocate memory on
    your behalf. In general Go can't function if it can't allocate
    memory. So there is no reason to let new and make return failure; if
    they can't succeed, your Go program can't run anyhow.

    Ian

    --
  • Lucio at Nov 29, 2012 at 6:52 am
    That means that no tests are necessary after invoking new() and make()? I
    haven't seen any mention of that, but I could just have overlooked the
    documentation.

    Lucio.
    On Thursday, 29 November 2012 08:49:24 UTC+2, Ian Lance Taylor wrote:

    On Wed, Nov 28, 2012 at 10:31 PM, Lucio <lucio...@gmail.com <javascript:>>
    wrote:
    It struck me that someone may have already brought this up and there may be
    interesting reasons to shoot it down: would it make sense to extend new()
    and make() to return an optional error code on failure?
    There are various times when Go will implicitly allocate memory on
    your behalf. In general Go can't function if it can't allocate
    memory. So there is no reason to let new and make return failure; if
    they can't succeed, your Go program can't run anyhow.

    Ian
    --
  • David Anderson at Nov 29, 2012 at 7:03 am
    In most modern operating systems, it's not actually possible to detect
    failure of memory allocation, because of optimistic allocation. If you try
    to use more memory than is available, your program will get killed by the
    OS without any possibility of intervening, because it's already at the
    point where it *has* to kill you to keep the system running.

    So, no, there are no tests necessary. new() and make() always returns the
    thing you requested.

    - Dave

    On Wed, Nov 28, 2012 at 10:52 PM, Lucio wrote:

    That means that no tests are necessary after invoking new() and make()? I
    haven't seen any mention of that, but I could just have overlooked the
    documentation.

    Lucio.
    On Thursday, 29 November 2012 08:49:24 UTC+2, Ian Lance Taylor wrote:
    On Wed, Nov 28, 2012 at 10:31 PM, Lucio wrote:
    It struck me that someone may have already brought this up and there may be
    interesting reasons to shoot it down: would it make sense to extend new()
    and make() to return an optional error code on failure?
    There are various times when Go will implicitly allocate memory on
    your behalf. In general Go can't function if it can't allocate
    memory. So there is no reason to let new and make return failure; if
    they can't succeed, your Go program can't run anyhow.

    Ian
    --

    --
  • Dave Cheney at Nov 29, 2012 at 7:03 am

    That means that no tests are necessary after invoking new() and make()? I
    haven't seen any mention of that, but I could just have overlooked the
    documentation.
    Your allocation will either succeed, or the program will panic.

    Interesting side note, read the source for bytes/buffer.go

    --
  • Dan Kortschak at Nov 29, 2012 at 7:06 am
    Is that error ever returned? My understanding was that an out of memory could not be recovered.
    On 29/11/2012, at 5:26 PM, "Dave Cheney" wrote:

    Interesting side note, read the source for bytes/buffer.go
    --
  • Dave Cheney at Nov 29, 2012 at 7:01 am
    I believe that is left as an exercise to the reader.

    On Thu, Nov 29, 2012 at 6:00 PM, Dan Kortschak
    wrote:
    Is that error ever returned? My understanding was that an out of memory could not be recovered.
    On 29/11/2012, at 5:26 PM, "Dave Cheney" wrote:

    Interesting side note, read the source for bytes/buffer.go
    --
  • Dan Kortschak at Nov 29, 2012 at 7:22 am
    Given that it's not possible to recover, even just to repanic as this does. Why bother?
    On 29/11/2012, at 5:31 PM, "Dave Cheney" wrote:

    I believe that is left as an exercise to the reader.
    --
  • Minux at Nov 29, 2012 at 9:17 am

    On Thu, Nov 29, 2012 at 3:00 PM, Dan Kortschak wrote:

    Is that error ever returned? My understanding was that an out of memory
    could not be recovered.
    OOM panic can't be recovered, but some kind of make() panic could be
    recovered.




    spoiler alert:
    http://play.golang.org/p/lQ63nqY5N4

    --
  • Dan Kortschak at Nov 29, 2012 at 10:09 am
    I didn't post it, but I tried a make([][1000]int, 1<<30) in a function, essentially like is done in makeSlice in bytes/buffer.go with a recover and repanic, and it looked to me like the recover didn't stop the initial panic. This was in the playground.

    On 29/11/2012, at 7:47 PM, "minux" wrote:


    On Thu, Nov 29, 2012 at 3:00 PM, Dan Kortschak wrote:
    Is that error ever returned? My understanding was that an out of memory could not be recovered.
    OOM panic can't be recovered, but some kind of make() panic could be recovered.




    spoiler alert:
    http://play.golang.org/p/lQ63nqY5N4

    --
  • Gorky Park at Dec 4, 2012 at 3:30 pm
    I tried to recover from failed make but it didn't work. When allocating too
    much, Windows says "throw: runtime: cannot map pages in arena address
    space" and everything stops there.

    It would be nice if there was some way to know one cannot allocate any more
    memory, and be able to continue running the program with the current
    allocation. Or is there something like system.AmountPhysicalRAM to serve as
    a guideline?

    --
  • Ian Lance Taylor at Nov 29, 2012 at 7:28 am

    On Wed, Nov 28, 2012 at 10:52 PM, Lucio wrote:
    That means that no tests are necessary after invoking new() and make()? I
    haven't seen any mention of that, but I could just have overlooked the
    documentation.
    That is correct: no tests are needed.

    Ian
    On Thursday, 29 November 2012 08:49:24 UTC+2, Ian Lance Taylor wrote:
    On Wed, Nov 28, 2012 at 10:31 PM, Lucio wrote:
    It struck me that someone may have already brought this up and there may
    be
    interesting reasons to shoot it down: would it make sense to extend
    new()
    and make() to return an optional error code on failure?
    There are various times when Go will implicitly allocate memory on
    your behalf. In general Go can't function if it can't allocate
    memory. So there is no reason to let new and make return failure; if
    they can't succeed, your Go program can't run anyhow.

    Ian
    --
    --
  • Lucio at Nov 29, 2012 at 9:32 am

    There are various times when Go will implicitly allocate memory on
    your behalf. In general Go can't function if it can't allocate
    memory. So there is no reason to let new and make return failure; if
    they can't succeed, your Go program can't run anyhow.
    I just had a thought...

    Given that Go handles allocation more or less seamlessly, would it not be
    advantageous to give new() and make() the additional feature of being able
    to report errors, no matter how serious?

    (I do get it: Go itself may not be able to continue in such a crisis; but
    one can program a bit defensively for that - NetBSD's 10% extra partition
    capacity comes to mind.)

    In my limited programming with Go I haven't encountered any instances where
    I could not choose to use new() instead of taking the address of an empty
    typed value. Actually, the reverse, as new() feels more conventional; but
    the crucial thing is that I would expect new() in this case to be better
    suited to return an optional completion code, unlike some alternatives.

    Just a thought while I unlearn the bad habits of the past few decades :-)

    Lucio.

    --
  • Dave Cheney at Nov 29, 2012 at 9:39 am
    Unrelated story. Tomcat keeps a 1mb byte array stashed away by the top
    level exception handler. If an oom error ever bubbles up to the top, the
    handler will null the reference to the buffer and try to continue to
    service requests.

    Dave
    On Thursday, November 29, 2012, Lucio wrote:

    There are various times when Go will implicitly allocate memory on
    your behalf. In general Go can't function if it can't allocate
    memory. So there is no reason to let new and make return failure; if
    they can't succeed, your Go program can't run anyhow.
    I just had a thought...

    Given that Go handles allocation more or less seamlessly, would it not be
    advantageous to give new() and make() the additional feature of being able
    to report errors, no matter how serious?

    (I do get it: Go itself may not be able to continue in such a crisis; but
    one can program a bit defensively for that - NetBSD's 10% extra partition
    capacity comes to mind.)

    In my limited programming with Go I haven't encountered any instances
    where I could not choose to use new() instead of taking the address of an
    empty typed value. Actually, the reverse, as new() feels more
    conventional; but the crucial thing is that I would expect new() in this
    case to be better suited to return an optional completion code, unlike some
    alternatives.

    Just a thought while I unlearn the bad habits of the past few decades :-)

    Lucio.

    --

    --
  • Jan Mercl at Nov 29, 2012 at 9:46 am

    On Thu, Nov 29, 2012 at 10:32 AM, Lucio wrote:
    I just had a thought...

    Given that Go handles allocation more or less seamlessly, would it not be
    advantageous to give new() and make() the additional feature of being able
    to report errors, no matter how serious?
    If "no matter how serious" then the error from the host OS might be
    "Bad process! No more memory for you" [think malloc(...) == NULL].
    Then there is possibly little, if any, way to report anything above
    that NULL as that again may need memory allocation. I mean, even
    printing/logging a message or even calling _any_ function at all
    (think split stacks may need to alloc mem anytime) cannot be
    guaranteed to work.

    -j

    --
  • Lucio at Nov 29, 2012 at 9:53 am
    I understand, entirely (and I said as much). But not being able to
    guarantee something and not wanting to provide it are different things. If,
    as Russ has reminded me many times, the quid pro quo is too heavy on one
    side, then the decision is much easier. In this case, I'm curious to see
    where in the scale of totally-ridiculous through
    we-really-ought-to-have-this my original suggestion actually fits.

    Lucio.
    On Thursday, 29 November 2012 11:40:35 UTC+2, Jan Mercl wrote:

    On Thu, Nov 29, 2012 at 10:32 AM, Lucio <lucio...@gmail.com <javascript:>>
    wrote:
    I just had a thought...

    Given that Go handles allocation more or less seamlessly, would it not be
    advantageous to give new() and make() the additional feature of being able
    to report errors, no matter how serious?
    If "no matter how serious" then the error from the host OS might be
    "Bad process! No more memory for you" [think malloc(...) == NULL].
    Then there is possibly little, if any, way to report anything above
    that NULL as that again may need memory allocation. I mean, even
    printing/logging a message or even calling _any_ function at all
    (think split stacks may need to alloc mem anytime) cannot be
    guaranteed to work.

    -j
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 29, '12 at 6:31a
activeDec 4, '12 at 3:30p
posts17
users8
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase