On 2/24/21 9:53 AM, roger peppe wrote: > On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick <m8il1i...@gmail.com > <mailto:m8il1i...@gmail.com>> wrote: > > I only instigate panic manually for one thing. Perhaps that will change, > but > I doubt it. > > If I want to send out or write a log to disk then I will call panic rather > than os.exit, upon a log.fatal scenario. Think buffered go routine > logging. > Saving the coder from having to think about it, once initialised. > > Which produces some ugly output and likely extra processing. > > Is it possible to call panic in a way that does not kill the process like > os.Exit, but without log pollution? > > I am solely thinking of manually instigated panics, so a noop panic called > something like terminate? > > Or is this bad practice, even when a program is in good operational order > when instigated, as the OS is better at cleanup? > > > Personally, I'd advise against using panic or log.Fatal in this kind of > context > - I'd just bite the bullet and return errors instead. > This makes it easy to move code between contexts if you need to without > worrying > about non-local control flow. >
Yes, I avoid log.Fatal, wherever possible. However, if I am for example running a drop privileges function and it fails then I want an immediate exit. To avoid any potential of fragility. Actually it seems that the panic never gets logged anyway and as the master process is unlikely to fatal then a panic is unlikely to ever be seen. Perhaps not ideal, but it works. > For unexpected panics, you can still use recover to flush your log buffers, > assuming the panic happens in code that's been called by your code. I think I would rather os.Exit ASAP, in the case of an unexpected panic. -- 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/84a0db02-c4ec-15cf-cdd9-8543c1f9aa61%40gmail.com.