I do think that panic should be avoided whenever possible. I had a third party library that panicked and crashed my application during the production run. If it were to return errors instead, I could have anticipated the problem and handled the situation with a bit more grace. The problem with panic is that it isn't obvious from the method signature that there is a possible alternate path. The author does not always document it. Thus, this hidden path is often unhandled and crashes the application. This may be acceptable during development phase, but not in the production run.
I am pretty sure panic has its uses, but at the moment there are still people who use panic as a rare error. An error is an error. If you can return an error, you should return an error, even if it is rare or near impossible to happen. The fact that panic is used as a rare error makes it even dangerous because they represent the corner cases that are often unanticipated by the developers. Nowadays I just wrap any third party library and use recover in case if any of them suddenly goes into shock and panic. On Monday, April 24, 2017 at 4:02:55 PM UTC+7, Sokolov Yura wrote: > Good day, people. > > Title is a bit controversial :-) > > I want to ask: > - how useful `recover` for you? > - Don't you think it is a bit "dangerous"? > > I mean: panic usually means programmer error, so if it happens, then > program behaves incorrectly, and there is always a chance of serious > state corruption. So, is there reason to recover at all? > > Also, presence of `recover` complicates implementation of `defer`. > I believe, it could be optimized much harder in absence of `recover` > (i.e. if program always exits on panic). > > I could be mistaken. > > Yura. > -- 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.
