On Tue, Apr 25, 2017 at 6:22 AM, Henry <henry.adisuma...@gmail.com> wrote:
> 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 fundamentally disagree. It is especially important during production runs. Because then it's about production traffic and production data and production users and not ignoring bugs during that time is especially important. It's not apparent when things can panic, but the basic rule of thumb is, that any non-trivial piece of code can panic, because any non-trivial piece of code can have bugs. That third-party library could've just as well divided by zero. And apparently, all that returning an error would've done, is giving you a false sense of security that this could never fail in an unpredictable way. But bugs are happening and bugs are unpredictable. I understand that it's frustrating to have software crash in production, I really do (see above). But the root-cause to fix this is not to ignore bugs that you know of and plough on, but to build layers of defense around failure, be it tests (I'd argue that any panic that isn't a *very* clear and serious code bug should be trivial to surface in tests), load-shedding, quick restarts, static analysis or formal proofs (whatever the level of security you want); because that also helps against the bugs you *don't* know of. > 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. > There is an important difference between "a rare error" and "a code bug". A rare error is, when opening a file will fail on a full-moon; a code bug is if you corrupt state or do obviously incorrect things. Of course the rarity of an error should not determine it's handling. 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. > -- 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.
