panicOn(err) error handling

[Jason E. Aten]

I find the following function solves all boilerplate issues of error handling in Go for me:

func panicOn(err error) {

    if err != nil { panic(err) }

}

I use it thus:

...

val, err := someFunctionThatCanReturnAnErr()

panicOn(err)

...

When more refined error handling is needed, it can be replaced.

I've never needed anything more, as a defult.  Perhaps we should add the equivalent as a built in, and recommend it to beginners.

[Brian Candler]

I don't think it's a good idea to recommend to beginners that they should write programs that crash.  Neither is teaching them a pattern that they will have to discard as soon as they write real programs.

Panic doesn't generates user-friendly error messages, it generates stacktraces for a programmer to analyze. Its main purpose is to deal with things which *should never have happened* and were not anticipated, like accessing a slice out of bounds: in other words, a panic means the *programmer* made a mistake.  If the *user* provides bad input, like giving the name of a file that doesn't exist, that certainly can be anticipated and handled in a sane way

If you want to give beginners some patterns, I'd start with these:

// for func main()

val, err := someFunctionThatCanReturnAnErr()

if err != nil {

    fmt.Printf("error doing XXX: %v", err)

    os.Exit(1)

}

// for a function which returns an err, and is happy to propagate that error upwards

val, err := someFunctionThatCanReturnAnErr()

if err != nil {

    return fmt.Errorf("error doing XXX: %v", err)

}

[Jason E. Aten]

On Wednesday, February 23, 2022 at 12:33:55 AM UTC-6 Brian Candler wrote:

I don't think it's a good idea to recommend to beginners that they should write programs that crash.  Neither is teaching them a pattern that they will have to discard as soon as they write real programs.

Au contraire. I don't want to belabor this, because its not a subtle point, and I think we mostly agree... although I find reading a panic stack trace, once quickly mastered, is usually the most informative thing.

I use panicOn(err) all the time in _real programs_, while constructing them. 

Its the default thing to write.

Its the default while I write the happy path, but it is a default that doesn't burn you badly. 

It doesn't make it hard to track down the bug when inevitably you forget to come back it and add in better error handling. Fixing a panic is typically quick and painless in comparison to tracking down an ignored error.

I find it is a perfectly appropriate to panic until you work out a better approach, because otherwise you'll forget to handle it, and a bad error will pass un-noticed. If perchance you never getting around to handling that "filesystem full" error, well, a panic in that case may be perfectly appropriate.

This is an incremental approach to growing a program, one that, most importantly, avoids the poor defaults of ignoring the error, or forgetting to ever handle the error.

 

[Brian Candler]

Of course, you should write your own programs which work in the way which suits you best.

If I understand your original post correctly, you are making two proposals:

1. Modifying the language to have some sort of shortcut for "if err != nil { panic(err) }"

2. Modifying Go documentation to tell newcomers to Go that this is a good pattern to adopt.

All I'm saying is that I disagree on both counts - but it's just a matter of one person's opinion over another.

[Axel Wagner]

On Wed, Feb 23, 2022 at 10:50 AM Brian Candler <b.ca...@pobox.com> wrote:

Of course, you should write your own programs which work in the way which suits you best.

If I understand your original post correctly, you are making two proposals:

1. Modifying the language to have some sort of shortcut for "if err != nil { panic(err) }"

2. Modifying Go documentation to tell newcomers to Go that this is a good pattern to adopt.

All I'm saying is that I disagree on both counts - but it's just a matter of one person's opinion over another.

FWIW I also disagree on both counts. And I feel comfortable in saying that while this might be an opinion, I believe it is one strongly held by a large majority of Go programmers. I can't see any future in which we would add a builtin like this to the language or where first party docs would recommend this. Third parties can, of course, recommend what they want.

On Wednesday, 23 February 2022 at 08:09:55 UTC Jason E. Aten wrote:

On Wednesday, February 23, 2022 at 12:33:55 AM UTC-6 Brian Candler wrote:

I don't think it's a good idea to recommend to beginners that they should write programs that crash.  Neither is teaching them a pattern that they will have to discard as soon as they write real programs.

Au contraire. I don't want to belabor this, because its not a subtle point, and I think we mostly agree... although I find reading a panic stack trace, once quickly mastered, is usually the most informative thing.

I use panicOn(err) all the time in _real programs_, while constructing them. 

Its the default thing to write.

Its the default while I write the happy path, but it is a default that doesn't burn you badly. 

It doesn't make it hard to track down the bug when inevitably you forget to come back it and add in better error handling. Fixing a panic is typically quick and painless in comparison to tracking down an ignored error.

I find it is a perfectly appropriate to panic until you work out a better approach, because otherwise you'll forget to handle it, and a bad error will pass un-noticed. If perchance you never getting around to handling that "filesystem full" error, well, a panic in that case may be perfectly appropriate.

This is an incremental approach to growing a program, one that, most importantly, avoids the poor defaults of ignoring the error, or forgetting to ever handle 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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dabc2126-94ee-49e2-9c5d-5018866d3ed8n%40googlegroups.com.