[jcelerier]

> It's designed to force people to handle the damn error as near to the call as possible.

which is sometimes impossible to do in any meaningful way which just leads people to put panic in there making the end-user experience much worse than having an exception handler at the base of the program / event loop

[dgellow]

In production code people put panics around? I’ve never seen a situation like this. The convention to not use panic is quite strong

[knz42]

And yet it certainly is there.

[andreygrehov]

Panics are rare events that very few functions should ever need to think about. If the library truly cannot set itself up, it might be reasonable to panic (which is why panics are usually in the `main` package only). Once all the invariants have been checked, there is no reason to panic anytime after.

[akvadrako]

Panic works fine; they are basically just exceptions you can catch at a higher level. I almost exclusively use panic for my exceptions in go.

[marcus_holmes]

I stopped, because it conflicts so badly with the Go conventions, and because I found myself handling more errors when I didn't use panic.

I think this is one of those things that new Gophers find hard to adjust to, and older ones realise the wisdom of (there's a few of these in the Go learning journey!).

I'm not impugning your expertise or implying that you're inexperienced. It's just something I've noticed.

[akvadrako]

For me it was the other direction. I started using err returns because I knew it was idiomatic, but after doing that for months and seeing no benefit I decided it was just idiotic to continue.

When I want to handle an error case locally I still use them, but that's extremely rare.