FAQ
I thought I'd share some fresh insight. I was searching through the Plan 9
sources to determine what I was missing that caused the mail components not
to work the way I had configured them.

I eventually identified a small section of code, some twenty lines of C,
that dealt with starting a TLS server from an X.509 certificate and its
private key. Thing is, the certificate is first parsed, then the
server-side TLS agent uses it to negotiate the connection.

What is pertinent is that the parsing function reports errors by setting a
return pointer to null, while the TLS negotiation returns a similarly
uninformative condition if the operation fails. In Go, because each of
these conditions need to be tested as they progress, it is so much more
likely that, at the end, there will be a descriptive message, unlike the
"TLS start-up failed with ..." that the Plan 9 code reports, no matter what
happens under the bonnet.

In other words, all these annoying

     if err != nil {
         "take notice of this particular micro-problem"
     }

that we pepper our Go sources with, are a blessing, not a curse. They also
add a mandatory layer of debug information that other languages suggest is
unnecessary.

I'm sold, maybe others can share similar experiences?

Lucio.

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

  • LMR at Sep 30, 2015 at 12:03 pm
    In general I agree with you.
    however, I'd like to see some kind of macro that gets expanded into those 3
    lines of code that is usually just tedious to do.
    In other languages with try/catch I always make sure I pass the right
    context, objects etc, so it' ain't any better... Again auto-expanding macro
    usually helps.

    disclaimer: there is probably something like this already. I just haven't
    looked into it yet

    On Tuesday, 29 September 2015 16:53:43 UTC+2, Lucio wrote:

    I thought I'd share some fresh insight. I was searching through the Plan
    9 sources to determine what I was missing that caused the mail components
    not to work the way I had configured them.

    I eventually identified a small section of code, some twenty lines of C,
    that dealt with starting a TLS server from an X.509 certificate and its
    private key. Thing is, the certificate is first parsed, then the
    server-side TLS agent uses it to negotiate the connection.

    What is pertinent is that the parsing function reports errors by setting a
    return pointer to null, while the TLS negotiation returns a similarly
    uninformative condition if the operation fails. In Go, because each of
    these conditions need to be tested as they progress, it is so much more
    likely that, at the end, there will be a descriptive message, unlike the
    "TLS start-up failed with ..." that the Plan 9 code reports, no matter what
    happens under the bonnet.

    In other words, all these annoying

    if err != nil {
    "take notice of this particular micro-problem"
    }

    that we pepper our Go sources with, are a blessing, not a curse. They
    also add a mandatory layer of debug information that other languages
    suggest is unnecessary.

    I'm sold, maybe others can share similar experiences?

    Lucio.
    --
    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.
  • Lucio De Re at Sep 30, 2015 at 1:08 pm
    Luca, the amount of text involved is minimal and any self-respecting
    editor can short-circuit the typing. You can't make the text more
    readable and, I'm sure, you don't want it LESS readable.

    Further, and here's the point I was trying to make, having to pay
    attention to EACH error instance means that the program is better
    documented when it fails, which one expects to be a rare occasion and
    consequently not as well exercised.

    In short, forcing errors to be dealt with means that you don't need
    the programmer's familiarity with the code to make the best of it. In
    my case, I eventually had to establish from various unrelated sources
    that certain undocumented features of certificate handling needed to
    be set, which appropriate error messaging would have disclosed.

    Lucio.

    --
    Lucio De Re
    2 Piet Retief St
    Kestell (Eastern Free State)
    9860 South Africa

    Ph.: +27 58 653 1433
    Cell: +27 83 251 5824
    FAX: +27 58 653 1435

    --
    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.
  • Lucio at Sep 30, 2015 at 1:16 pm
    I'll need to remember NOT to reply in email, I really oughtn't to add my
    signature on this forum.

    Lucio.

    --
    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.
  • LMR at Sep 30, 2015 at 1:36 pm
    as I said, I agree on your point.
    I'll have to upgrade to an half decent editor then :-)
    On Wednesday, 30 September 2015 15:15:55 UTC+2, Lucio wrote:

    I'll need to remember NOT to reply in email, I really oughtn't to add my
    signature on this forum.

    Lucio.
    --
    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.
  • Pieter Droogendijk at Sep 30, 2015 at 1:45 pm
    You could try something like this: http://play.golang.org/p/Kjt34Nev15

    I usually use something like that early on in a project for the PoC. I
    should put it in a package so I don't re-invent the wheel every time, but
    it's so little work... I think I'll do it tonight.

    In simple things (usually command-line utilities) I often don't even bother
    with Recover.

    --
    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.
  • LMR at Sep 30, 2015 at 3:50 pm
    Thanks Pieter. I had done something similar with other languages... never
    got around it in GO...
    thanks for sharing it
    On Wednesday, 30 September 2015 15:45:02 UTC+2, Pieter Droogendijk wrote:

    You could try something like this: http://play.golang.org/p/Kjt34Nev15

    I usually use something like that early on in a project for the PoC. I
    should put it in a package so I don't re-invent the wheel every time, but
    it's so little work... I think I'll do it tonight.

    In simple things (usually command-line utilities) I often don't even
    bother with Recover.
    --
    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.
  • Giulio Iotti at Sep 30, 2015 at 4:34 pm

    On Wednesday, September 30, 2015 at 6:50:04 PM UTC+3, LMR wrote:
    Thanks Pieter. I had done something similar with other languages... never
    got around it in GO...
    thanks for sharing it
    Although the example misusing panic() and recover() is more flexible, I
    suggest this: https://play.golang.org/p/avQnMIss3J

    This way is much more idiomatic and commonly used in tests.

    --
    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.
  • Pieter Droogendijk at Sep 30, 2015 at 4:40 pm
    If you have a bunch of calls with identical signatures, yes.

    In that way I think you may have misunderstood my example.

    --
    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.
  • Giulio Iotti at Sep 30, 2015 at 4:43 pm

    On Wednesday, September 30, 2015 at 7:40:49 PM UTC+3, Pieter Droogendijk wrote:

    If you have a bunch of calls with identical signatures, yes.

    In that way I think you may have misunderstood my example.
    No, I didn't; I wrote your method is indeed more flexible. It's also a big
    misuse of panic() and recover() and I wouldn't suggest it.

    --
    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.
  • Pieter Droogendijk at Sep 30, 2015 at 4:54 pm
    Why not?

    I'm not convinced it's a misuse either. It's certainly a use of panic and defer, but it's hidden and unobstructive.

    It may not be idiomatic, but it is exactly what OP asked for. And if we're only supposed to use patterns that are idiomatic, we'd never see truly gorgeous things like this:

    defer Trace("DoSomething")()

    (Which I did not come up with)

    --
    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.
  • Giulio Iotti at Sep 30, 2015 at 6:37 pm

    On Wednesday, September 30, 2015 at 7:54:02 PM UTC+3, Pieter Droogendijk wrote:

    Why not?

    I'm not convinced it's a misuse either. It's certainly a use of panic and
    defer, but it's hidden and unobstructive.
    I guess I am just irrationally allergic to panic().

    I just stumbled upon this in the standard library:
    https://golang.org/src/encoding/gob/error.go

    --
    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.
  • Joe Taber at Sep 30, 2015 at 7:10 pm
    This panic/recover pattern is especially applicable to parsers and other
    recursive programs where it's especially cumbersome to unwind a complex
    arbitrarily deep stack. E.g. something similar is also used in encoding/json
    <https://golang.org/src/encoding/json/decode.go#L139> and is mentioned
    explicitly in a post on the Go Blog: Defer, Panic and Recover
    <https://blog.golang.org/defer-panic-and-recover>. But the presence of this
    pattern in these specific circumstances in the standard library doesn't
    necessarily endorse it for all other applications.

    A quote from that post to keep in mind: "The convention in the Go libraries
    is that even when a package uses panic internally, its external API still
    presents explicit error return values."
    On Wednesday, September 30, 2015 at 1:37:09 PM UTC-5, Giulio Iotti wrote:

    On Wednesday, September 30, 2015 at 7:54:02 PM UTC+3, Pieter Droogendijk
    wrote:
    Why not?

    I'm not convinced it's a misuse either. It's certainly a use of panic and
    defer, but it's hidden and unobstructive.
    I guess I am just irrationally allergic to panic().

    I just stumbled upon this in the standard library:
    https://golang.org/src/encoding/gob/error.go

    --
    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.
  • Pieter Droogendijk at Sep 30, 2015 at 7:44 pm
    I've never needed much endorsement to use a feature in a way that works,
    even if it seems weird. I get that there's some hesitation because panics
    are panics, but other than not being particularly idiomatic or endorsed,
    are there any serious drawbacks to using this pattern?

    And keeping panics from crossing library bounds is good practice, but I'm
    not sure invoking it in this case makes much sense. After all, the whole
    point of this method is to present explicit error return values.
    On Wednesday, September 30, 2015 at 9:09:57 PM UTC+2, Joe Taber wrote:

    This panic/recover pattern is especially applicable to parsers and other
    recursive programs where it's especially cumbersome to unwind a complex
    arbitrarily deep stack. E.g. something similar is also used in
    encoding/json <https://golang.org/src/encoding/json/decode.go#L139> and
    is mentioned explicitly in a post on the Go Blog: Defer, Panic and Recover
    <https://blog.golang.org/defer-panic-and-recover>. But the presence of
    this pattern in these specific circumstances in the standard library
    doesn't necessarily endorse it for all other applications.

    A quote from that post to keep in mind: "The convention in the Go
    libraries is that even when a package uses panic internally, its external
    API still presents explicit error return values."
    On Wednesday, September 30, 2015 at 1:37:09 PM UTC-5, Giulio Iotti wrote:

    On Wednesday, September 30, 2015 at 7:54:02 PM UTC+3, Pieter Droogendijk
    wrote:
    Why not?

    I'm not convinced it's a misuse either. It's certainly a use of panic
    and defer, but it's hidden and unobstructive.
    I guess I am just irrationally allergic to panic().

    I just stumbled upon this in the standard library:
    https://golang.org/src/encoding/gob/error.go

    --
    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.
  • Pieter Droogendijk at Sep 30, 2015 at 7:36 pm

    On Wednesday, September 30, 2015 at 8:37:09 PM UTC+2, Giulio Iotti wrote:

    I guess I am just irrationally allergic to panic().
    Fair enough :)

    I just stumbled upon this in the standard library:
    https://golang.org/src/encoding/gob/error.go
    Heh, so I'm not even original. Dang 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.
  • LMR at Sep 30, 2015 at 7:54 pm
    Giulio:

    I remember reading somewhere that Panic is supposed to be used only for
    real system panic...
    however your link shows another description... So I'm going to give
    Pieter's code another consideration. I was going to say the same about the
    use of Panic to Pieter...

    FWIW I found his code more readeable... but that's just me and my
    background probably

    Thank you both for the frank discussion.


    On Wednesday, 30 September 2015 20:37:09 UTC+2, Giulio Iotti wrote:

    On Wednesday, September 30, 2015 at 7:54:02 PM UTC+3, Pieter Droogendijk
    wrote:
    Why not?

    I'm not convinced it's a misuse either. It's certainly a use of panic and
    defer, but it's hidden and unobstructive.
    I guess I am just irrationally allergic to panic().

    I just stumbled upon this in the standard library:
    https://golang.org/src/encoding/gob/error.go

    --
    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.
  • S at Sep 30, 2015 at 10:28 pm
    I wrapped this pattern up in a library that I use regularly now when
    prototyping. I find that having the line numbers as part of the error
    message is useful. I usually end up unwrapping some of these once the code
    is stable though.

    https://github.com/surullabs/fault

    Some utilities for testing when using the above:

    https://github.com/surullabs/testfault

    The main reason I end up unwrapping some things is that code coverage
    information is misleading with this pattern.

    Here's some sample usage:

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

    Sridhar
    On Wednesday, September 30, 2015 at 9:54:30 PM UTC+2, LMR wrote:

    Giulio:

    I remember reading somewhere that Panic is supposed to be used only for
    real system panic...
    however your link shows another description... So I'm going to give
    Pieter's code another consideration. I was going to say the same about the
    use of Panic to Pieter...

    FWIW I found his code more readeable... but that's just me and my
    background probably

    Thank you both for the frank discussion.


    On Wednesday, 30 September 2015 20:37:09 UTC+2, Giulio Iotti wrote:

    On Wednesday, September 30, 2015 at 7:54:02 PM UTC+3, Pieter Droogendijk
    wrote:
    Why not?

    I'm not convinced it's a misuse either. It's certainly a use of panic
    and defer, but it's hidden and unobstructive.
    I guess I am just irrationally allergic to panic().

    I just stumbled upon this in the standard library:
    https://golang.org/src/encoding/gob/error.go

    --
    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:12 am

    On Wed, Sep 30, 2015 at 12:54:29PM -0700, LMR wrote:
    I remember reading somewhere that Panic is supposed to be used only for
    real system panic...
    I think that's one of these half-truths they tell to newbies so they won't try writing Java in Go.

    --
    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.
  • Henrik Johansson at Oct 1, 2015 at 11:52 am
    The essence of it is to use it where appropriate and while that might not
    mean anything in itself the advice given to not use it so much is simply a
    hint but probably a well grounded hint. I can't remember ever using it
    unless it was not possible to continue so I find myself adhering to the
    advice.

    tors 1 okt. 2015 kl 13:12 skrev Staven <staven@staven.pl>:
    On Wed, Sep 30, 2015 at 12:54:29PM -0700, LMR wrote:
    I remember reading somewhere that Panic is supposed to be used only for
    real system panic...
    I think that's one of these half-truths they tell to newbies so they won't
    try writing Java in Go.

    --
    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.
    --
    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.
  • LMR at Oct 1, 2015 at 1:18 pm
    @Staven:you made me smile :-)

    On Thursday, 1 October 2015 13:13:11 UTC+2, Staven wrote:
    On Wed, Sep 30, 2015 at 12:54:29PM -0700, LMR wrote:
    I remember reading somewhere that Panic is supposed to be used only for
    real system panic...
    I think that's one of these half-truths they tell to newbies so they won't
    try writing Java in Go.
    --
    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
postedSep 29, '15 at 2:54p
activeOct 1, '15 at 1:18p
posts20
users8
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase