FAQ
Hi,

I have this 2 lines of code:

parsedCapacity, _ := strconv.ParseInt(formCapacity, 10, 0)
capacity := int(parsedCapacity)

As you can see I am ignoring the second return parameter, the error,
parsedCapacity is int64 and for simplicity I am casting capacity to int.

Is there any other way to write this 2 lines of code?

parsedCapacity for me acts like a temporary variable, I would like to be
able to do the conversion and casting without having to maintain this
temporary variable of undesirable type.

Thanks,
DC

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

  • Ian Lance Taylor at Nov 22, 2013 at 4:50 pm

    On Fri, Nov 22, 2013 at 8:46 AM, Danilo Cabello wrote:

    I have this 2 lines of code:

    parsedCapacity, _ := strconv.ParseInt(formCapacity, 10, 0)
    capacity := int(parsedCapacity)

    As you can see I am ignoring the second return parameter, the error,
    parsedCapacity is int64 and for simplicity I am casting capacity to int.

    Is there any other way to write this 2 lines of code?

    parsedCapacity for me acts like a temporary variable, I would like to be
    able to do the conversion and casting without having to maintain this
    temporary variable of undesirable type.
    In general, no, that is the only way to do this kind of thing.

    In this particular case, use strconv.Atoi.

    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.
  • Robert Johnstone at Nov 22, 2013 at 5:09 pm
    It the pattern occurs repeatedly, and you are confident that ignoring the
    error is safe, you could wrap strconv.ParseInt in a function. There is a
    convention of prefixing functions that ignore errors with "Must". You end
    up with the following:

    http://play.golang.org/p/Qoo-o9IBNN


    On Friday, 22 November 2013 11:46:24 UTC-5, Danilo Cabello wrote:

    Hi,

    I have this 2 lines of code:

    parsedCapacity, _ := strconv.ParseInt(formCapacity, 10, 0)
    capacity := int(parsedCapacity)

    As you can see I am ignoring the second return parameter, the error,
    parsedCapacity is int64 and for simplicity I am casting capacity to int.

    Is there any other way to write this 2 lines of code?

    parsedCapacity for me acts like a temporary variable, I would like to be
    able to do the conversion and casting without having to maintain this
    temporary variable of undesirable type.
    --
    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.
  • Harald Weidner at Nov 26, 2013 at 11:50 pm

    Am Freitag, 22. November 2013 18:09:15 UTC+1 schrieb Robert Johnstone:
    It the pattern occurs repeatedly, and you are confident that ignoring the
    error is safe, you could wrap strconv.ParseInt in a function. There is a
    convention of prefixing functions that ignore errors with "Must".
    In most of my programs, I define a generic "must" function that strips off
    the error and returns the other return value.

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

    This allows to concatenate function calls even when they return an error as
    a second return value. It is especially useful in web applications, where a
    proper panic handler is already present.

    The drawback is, however, that a type assertion is needed for the result,
    unless it is passed to a function which takes interface{} arguments (like
    fmt.Println).

    IMO, the "Must" pattern is so idiomatic that Go should provide a builtin
    must() function which does the same, but for a variadic number of
    parameters before the error, and without type assertion (by type
    inheritance). Just my opinion...

    Harald

    --
    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.
  • Dave Cheney at Nov 27, 2013 at 12:00 am

    On Wed, Nov 27, 2013 at 10:50 AM, Harald Weidner wrote:

    Am Freitag, 22. November 2013 18:09:15 UTC+1 schrieb Robert Johnstone:
    It the pattern occurs repeatedly, and you are confident that ignoring the
    error is safe, you could wrap strconv.ParseInt in a function. There is a
    convention of prefixing functions that ignore errors with "Must".

    In most of my programs, I define a generic "must" function that strips off
    the error and returns the other return value.

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

    This allows to concatenate function calls even when they return an error as
    a second return value. It is especially useful in web applications, where a
    proper panic handler is already present.

    The drawback is, however, that a type assertion is needed for the result,
    unless it is passed to a function which takes interface{} arguments (like
    fmt.Println).

    IMO, the "Must" pattern is so idiomatic that Go should provide a builtin
    must() function which does the same, but for a variadic number of parameters
    before the error, and without type assertion (by type inheritance). Just my
    opinion...
    I disagree. Adding a must() builtin function would send the wrong
    message that Go favours panics over explicit error handling.

    Cheers

    Dave
    Harald

    --
    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.
  • Kevin Gillette at Nov 27, 2013 at 1:47 am
    Not to mention that while `func Must(i int, _ error) { return i }` can be
    inlined and potentially result in a nop, the aforementioned generic Must
    implementation is only generic for two-argument inputs, and more
    importantly, the cost of boxing/unboxing at runtime is extremely high
    considering you're only saving one line of code, and that most gophers have
    learned to embrace the idea that, even when all else is equal, a one-line
    savings is no savings at all.
    On Tuesday, November 26, 2013 5:00:11 PM UTC-7, Dave Cheney wrote:
    On Wed, Nov 27, 2013 at 10:50 AM, Harald Weidner wrote:


    Am Freitag, 22. November 2013 18:09:15 UTC+1 schrieb Robert Johnstone:
    It the pattern occurs repeatedly, and you are confident that ignoring
    the
    error is safe, you could wrap strconv.ParseInt in a function. There is
    a
    convention of prefixing functions that ignore errors with "Must".

    In most of my programs, I define a generic "must" function that strips off
    the error and returns the other return value.

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

    This allows to concatenate function calls even when they return an error as
    a second return value. It is especially useful in web applications, where a
    proper panic handler is already present.

    The drawback is, however, that a type assertion is needed for the result,
    unless it is passed to a function which takes interface{} arguments (like
    fmt.Println).

    IMO, the "Must" pattern is so idiomatic that Go should provide a builtin
    must() function which does the same, but for a variadic number of
    parameters
    before the error, and without type assertion (by type inheritance). Just my
    opinion...
    I disagree. Adding a must() builtin function would send the wrong
    message that Go favours panics over explicit error handling.

    Cheers

    Dave
    Harald

    --
    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...@googlegroups.com <javascript:>.
    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.
  • Danilo Cabello at Nov 27, 2013 at 7:46 pm
    Thanks guys, I guess a mustParseInt function in my codebase is a good
    option.


    On Tue, Nov 26, 2013 at 8:47 PM, Kevin Gillette
    wrote:
    Not to mention that while `func Must(i int, _ error) { return i }` can be
    inlined and potentially result in a nop, the aforementioned generic Must
    implementation is only generic for two-argument inputs, and more
    importantly, the cost of boxing/unboxing at runtime is extremely high
    considering you're only saving one line of code, and that most gophers have
    learned to embrace the idea that, even when all else is equal, a one-line
    savings is no savings at all.
    On Tuesday, November 26, 2013 5:00:11 PM UTC-7, Dave Cheney wrote:

    On Wed, Nov 27, 2013 at 10:50 AM, Harald Weidner <hweidne...@gmx.net>
    wrote:

    Am Freitag, 22. November 2013 18:09:15 UTC+1 schrieb Robert Johnstone:
    It the pattern occurs repeatedly, and you are confident that ignoring
    the
    error is safe, you could wrap strconv.ParseInt in a function. There
    is a
    convention of prefixing functions that ignore errors with "Must".

    In most of my programs, I define a generic "must" function that strips off
    the error and returns the other return value.

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

    This allows to concatenate function calls even when they return an error as
    a second return value. It is especially useful in web applications, where a
    proper panic handler is already present.

    The drawback is, however, that a type assertion is needed for the result,
    unless it is passed to a function which takes interface{} arguments (like
    fmt.Println).

    IMO, the "Must" pattern is so idiomatic that Go should provide a builtin
    must() function which does the same, but for a variadic number of
    parameters
    before the error, and without type assertion (by type inheritance). Just my
    opinion...
    I disagree. Adding a must() builtin function would send the wrong
    message that Go favours panics over explicit error handling.

    Cheers

    Dave
    Harald

    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/UYF5RzHPhG4/unsubscribe.
    To unsubscribe from this group and all its topics, 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.
  • Djadala at Nov 27, 2013 at 1:19 am
    http://play.golang.org/p/NPBxCViv1x
    On Friday, November 22, 2013 6:46:24 PM UTC+2, Danilo Cabello wrote:

    Hi,

    I have this 2 lines of code:

    parsedCapacity, _ := strconv.ParseInt(formCapacity, 10, 0)
    capacity := int(parsedCapacity)

    As you can see I am ignoring the second return parameter, the error,
    parsedCapacity is int64 and for simplicity I am casting capacity to int.

    Is there any other way to write this 2 lines of code?

    parsedCapacity for me acts like a temporary variable, I would like to be
    able to do the conversion and casting without having to maintain this
    temporary variable of undesirable type.

    Thanks,
    DC
    --
    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
postedNov 22, '13 at 4:46p
activeNov 27, '13 at 7:46p
posts8
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase