Re: [go-nuts] Re: panicOn(err) error handling
On Wed, Feb 23, 2022 at 10:50 AM Brian Candler 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+unsubscr...@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
>
> .
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGLPN866MKr6H1e%3DXBbS1Cnsk952Tg5sXrbKvc1BR26cA%40mail.gmail.com.
[go-nuts] Re: panicOn(err) error handling
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.
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+unsubscr...@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.
[go-nuts] Re: panicOn(err) error handling
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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4c893529-f000-4855-8715-cc1f458efddan%40googlegroups.com.
[go-nuts] Re: panicOn(err) error handling
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)
}
On Wednesday, 23 February 2022 at 06:04:52 UTC Jason E. Aten wrote:
> 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.
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/f88e07df-04dc-4665-96ec-0ddd2535a00dn%40googlegroups.com.
