FAQ
I was wondering, if there's lots of code like:
if err != nil{
   somekindalog.log("Error trying to foo: the blah %v was expected to be a
blaz in order to do bleep because foomp, but was actually a blop\n",
someBlah)
}
Is it acceptable to treat the error string as a comment substitute, a
replacement for writing a comment like "//here the blah is used as a blaz
to bleep because foomp"?

--
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/d/optout.

Search Discussions

  • Giulio Iotti at Oct 1, 2015 at 7:24 am

    On Thursday, October 1, 2015 at 8:57:03 AM UTC+2, jonathan....@gmail.com wrote:

    I was wondering, if there's lots of code like:
    if err != nil{
    somekindalog.log("Error trying to foo: the blah %v was expected to be a
    blaz in order to do bleep because foomp, but was actually a blop\n",
    someBlah)
    }
    Is it acceptable to treat the error string as a comment substitute, a
    replacement for writing a comment like "//here the blah is used as a blaz
    to bleep because foomp"?
    I think they should convey different information.

    The logged info tells the user what he/she has done wrong (and possibly
    what should have done instead).
    The comment in code explains something that is not obvious when reading the
    code itself.

    In your example you assume the user knows what blop and foomp are and why
    the program expects one instead of the other (which might be an
    implementation detail, depending on what you mean in the example.)

    --
    Giulio Iotti

    --
    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/d/optout.
  • Staven at Oct 1, 2015 at 11:09 am

    On Wed, Sep 30, 2015 at 11:56:17PM -0700, jonathan.t.barnard@gmail.com wrote:
    I was wondering, if there's lots of code like:
    if err != nil{
    somekindalog.log("Error trying to foo: the blah %v was expected to be a
    blaz in order to do bleep because foomp, but was actually a blop\n",
    someBlah)
    }
    I hope you don't have a lot of code like that, because you're dropping the error
    instead of reporting it, which is *usually* not a good thing to do.
    Is it acceptable to treat the error string as a comment substitute, a
    replacement for writing a comment like "//here the blah is used as a blaz
    to bleep because foomp"?
    We should really make a distinction here between an *error value*, ie. a value
    implementing the error interface, and an error message displayed to the end user,
    even though the later ends up being included in the former.

    If your comment would say *exactly* the same thing as the error, there's
    absolutely no point writing it. Writing the same thing twice would just
    be visual noise.

    It makes sense, however, to skip internal information useless to the end user
    in the error log (as long as the error message unambiguously identifies the error condition),
    and put the rest of the relevant information in a comment.

    For example, if your .foo file parser failed to open a file because of a missing BAR header,
    you can print "failed to open /some/path.foo: missing BAR header". The user doesn't need to
    know what a BAR header is, or why your program needs it. She only needs to know that either
    path.foo is broken, or your program is broken. If the file is broken, that's not your problem.
    If your program is broken, she can copypasta the error and send it to you.
    You, on the other hand, can look at the source code and read the comment (hopefully located
    somewhere near the "missing BAR header" error string) explaining exactly what the hell
    a BAR header is and what you're trying to do with it.

    --
    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/d/optout.
  • Jonathan T Barnard at Oct 1, 2015 at 2:55 pm
    Right, I was thinking in the context of writing servers where the user is
    usually the developer, and didn't consider that it's not applicable to
    situations where they differ.

    I hope you don't have a lot of code like that, because you're dropping the
    error
    instead of reporting it, which is *usually* not a good thing to do.

    Oops, that was a bug in my pseudo code; real code would of course do
    something with the 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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 1, '15 at 6:56a
activeOct 1, '15 at 2:55p
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase