I've been writing some Go code. Earlier in my experience, I've avoided panicking rigorously, paving the way for "robust" software with plenty of verbose error checking.

There comes a point though where you start to miss having exceptions and throws. However, that is essentially what panics are, if a bit simpler. Panics are just exceptions that aren't really meant to be handled by implementation. The code simply crashes and recovers at a checkpoint.

In many cases, there are errors that are difficult or impossible to handle. The best way to handle them is to simply log them and crash. Ideally your entire program won't crash - just the current context will be terminated.

I've introduced in my design two types of panics:

(1) Uncontrolled panic

(2) Controlled panic

Uncontrolled is my label for bugs that need to be addressed. They should never happen. If they do, I print a stack trace and an error in the log to help out the maintenance team.

Controlled panics are still "unexpected" errors, but they are to handle situations that we don't care to handle, as the context cannot continue. So, technically I do "expect" them, but only under poor execution conditions.

For example, if we cannot commit a database transaction due to a network error, I'll start a "controlled panic", terminate the context, and log the error. The program recovers and continues. The error is mainly logged for cases where there is an environment issue that can be corrected.

Any other "expected" errors are done through normal error passing. Striking a balance between passing around errors and panicking can do a lot of good for the health of your codebase (though probably not a good idea if you're writing a library).

Think of it like interface exposure. One direction is to expose the error like a public interface. The other direction is to keep it private, simply panic, and not clutter the code with error handling implementation which would typically do the same thing - log the incident and terminate.