FAQ
Yes! I agree with this. It is quite easy to get bitten by this -- not
capturing and checking errors. If you _can_ ignore them, you should do so
explicitly! Otherwise, the compiler should tell you.

All the best,

:) Hein
On Saturday, March 17, 2012 12:28:56 PM UTC+1, Sebastien Paolacci wrote:

Not directly linked, but the only way I could see error handling
improved is by (compiler-side) forcing explicit discard of unused
return values:

CanFail() // Silent discard.
_ = CanFail() // Explicit discard.

Actually, I would even like the compiler to prevent me from discarding
any `error'-typed return value (yes, not that simple...).

Sebastien
--

Search Discussions

  • Jan Mercl at Nov 3, 2012 at 11:22 pm

    On Sun, Nov 4, 2012 at 12:14 AM, Hein Meling wrote:
    Yes! I agree with this. It is quite easy to get bitten by this -- not
    capturing and checking errors. If you _can_ ignore them, you should do so
    explicitly! Otherwise, the compiler should tell you.
    _, _ = fmt.Printf("Hello World") // Are you sure you really want to write this?

    -j

    --
  • Dustin Sallings at Nov 3, 2012 at 11:33 pm

    Jan Mercl writes:
    On Sun, Nov 4, 2012 at 12:14 AM, Hein Meling wrote:
    Yes! I agree with this. It is quite easy to get bitten by this -- not
    capturing and checking errors. If you _can_ ignore them, you should do so
    explicitly! Otherwise, the compiler should tell you.
    _, _ = fmt.Printf("Hello World") // Are you sure you really want to write this?
    gcc allows you to flag a return value as "shouldn't be ignored" or
    similar.

    I'm not attempting to add merit to the proposal, but that there's a
    middle ground between must not ignore errors and "what about printf?"

    --
    dustin

    --
  • Hein Meling at Nov 3, 2012 at 11:45 pm
    Huh! Right, I'd rather not have to write that mess, no!

    So, what would be a better approach then??

    What if the function were to declare that an error must be checked? Then
    users would be forced to remember error checking with a compile error. And
    obviously functions like those in fmt should not be checked.

    :) Hein

    On Sunday, November 4, 2012 12:22:27 AM UTC+1, Jan Mercl wrote:
    On Sun, Nov 4, 2012 at 12:14 AM, Hein Meling wrote:
    Yes! I agree with this. It is quite easy to get bitten by this -- not
    capturing and checking errors. If you _can_ ignore them, you should do so
    explicitly! Otherwise, the compiler should tell you.
    _, _ = fmt.Printf("Hello World") // Are you sure you really want to write
    this?

    -j
    --
  • Tiny_dust at Nov 4, 2012 at 2:27 am
    the main point is:

    (1) if error occurs,but user do not check it , gc should fall back to
    panic automatically.
    (2) if error does not occurs,and user do not check it . the program
    go ahead silently.


    so:

    fmt.Print(xxxx) could work as before.
    but if the returned error value is not nil ,program panic.
    the proposal is safer and cleaner.

    it does not force us writer _,_=fmt.Println(xxx)




    On 11月4日, 上午7时44分, Hein Meling wrote:
    Huh! Right, I'd rather not have to write that mess, no!

    So, what would be a better approach then??

    What if the function were to declare that an error must be checked? Then
    users would be forced to remember error checking with a compile error. And
    obviously functions like those in fmt should not be checked.

    :) Hein






    On Sunday, November 4, 2012 12:22:27 AM UTC+1, Jan Mercl wrote:

    On Sun, Nov 4, 2012 at 12:14 AM, Hein Meling <hein....@gmail.com<javascript:>>
    wrote:
    Yes! I agree with this. It is quite easy to get bitten by this -- not
    capturing and checking errors. If you _can_ ignore them, you should do so
    explicitly! Otherwise, the compiler should tell you.
    _, _ = fmt.Printf("Hello World") // Are you sure you really want to write
    this?
    -j
    --
  • DisposaBoy at Nov 4, 2012 at 8:28 am

    On Sunday, November 4, 2012 2:27:35 AM UTC, tiny_dust wrote:
    the main point is:

    (1) if error occurs,but user do not check it , gc should fall back to
    panic automatically.
    (2) if error does not occurs,and user do not check it . the program
    go ahead silently.


    so:

    fmt.Print(xxxx) could work as before.
    but if the returned error value is not nil ,program panic.
    the proposal is safer and cleaner.

    it does not force us writer _,_=fmt.Println(xxx)


    except, by your point 1, it does.
    If you write a call such as fmt.Print(...) and you don't check the error,
    it's because you don't care whether the call succeeded or not. It's easy to
    pick on .Print but the same applies to other common cases like reading
    where you get io.EOF. Only you can know whether that io.EOF is expected or
    not and in the case that you don't check a call to .Read() etc. because you
    just want to read what's available, what you end up with is that your
    program starts panic()ing for no good reason whatsoever. This approach
    simply increases complexity by starting the guessing game and makes code
    needlessly britle for what is IMHO no reasonable gain whatsoever

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 3, '12 at 11:14p
activeNov 4, '12 at 8:28a
posts6
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase