I had a few library functions which I couldn't decide on a "fits all" handling
method. Often the decision is based on the caller's environment. So I decided
to let the caller decide.
// Panic holds an optional user function which is used to handle serious
// run-time errors. If not set, the default (panic) is used.
//
// Examples:
// math.Panic = func(err error) { log.Fatal(err) } // Log and panic
// math.Panic = func(err error) { log.Warn(err) } // Log and continue
// math.Panic = func(err error) { } // Ignore and continue
//
var Panic func(error) = func(err error) { panic(err) } // Default: panic
Also, this avoids using recover - which gets really messy if you have multiple
spots where such an error can take place and the desired response might vary.
John
John Souvestre - New Orleans LA
-----Original Message-----
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Dave Cheney
Sent: 2017 April 27, Thu 16:54
To: golang-nuts
Subject: Re: [go-nuts] Re: Recover considered harmful
The take away for me is; prefer returning an error to to caller wherever
possible. Overuse of panic begats overuse of recover and that just leads to
more problems [1].
1. https://github.com/golang/go/issues/13879
--
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.
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
