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.
