"Always handle errors" sounds good until you remember that every read or write can potentially fail. My go programs are littered with unchecked fmt.Printf or Println statements.
If fmt.Print doesn't work, you should probably just kill the process.
Though, continuing to spend time generating more output that goes nowhere may not be particularly useful either, depending on what the program does.
Still I think ignoring errors writing to stdout is better as a general default. If nothing else, it’s the most common behavior and is thus more likely to fit the user’s expectations.
Actually, I'm reminded of certain errors I've seen along the lines of "exception raised while handing exception".
if so, get the error and evaluate it -- like if json.Marshal fails in your http.Handler
if not, (shrug) -- like (maybe) if your fmt.Printf fails
panics are for core assertion violations, not an ersatz error reporting mechanism