catch (Exception ex) { };

If you've going to catch an error with a noop, there better be a comment explaining why you're not doing anything. It's not often, but sometimes, failing gracefully is just swallowing the error and moving on.

Also, only do it for exceptions you think might actually hit there and you're OK with quietly squashing. Otherwise, please let something else try and handle it.

I have plenty of monitors to ensure my services are available (four-nines uptime for almost a decade). Internet unavailable errors are useless to log.

I think the problem is that some people think errors are supposed to happen. Just a cost of doing business. They can't be fixed, only mitigated.

The single line that magically fixes all Visual Basic 6 applications bugs

* if the input data field for a telephone number contains a country name do you communicate that error back to the source, if yes how and how often (assuming your source isn't a life user bit a bureaucratic institution)

* if there is an error that really shouldn't happen, how will you notice? You probably don't have all the logs scrolling on 100 displays to watch for the red. So maybe send emails? But if you send emails about pointless stuff people will start to ignore them

// this never happens

... guess what happened?

/happenings

I wouldn't use the advice in this article. It's quite old and the stdlib now has support for new stuff via error wrapping.

I like error wrapping. I've worked in codebases where systems had to be debugged by piecing together individual log lines. With error wrapping I can usually see the exact path that lead to the error in one line.

That way you’d be able to trace the stack of functions that were involved in passing an error back up to the place where it’s actually handled.

https://pkg.go.dev/github.com/pkg/errors

This is called a stack trace, and I agree it can be very useful (if the developers were thoughtful about their error handling)

Agreed. How I articulate it, often a function is just another layer, does one core thing and one-two extras. I wrap meticulously the errors of the extras. The core errors mainly speak for themselves, so they rarely need any wrapping.

Avoids:

    cannot load config:  cannot load config: cannot load config: file not found

    cannot load config: cannot connect to Configurer: loading client cert: PEM invalid

In my experience it's usually useful though, it usually tells you both what the problem is and where it is. Sadly a lot of people just don't even try to read them.

The complaint of developers "being reliant on stack traces" tone sounds an awful lot like: "real programmers just use punch cards and ignore any tooling we've come up with in the last 70 years: just use your brain"

There is something to the philosophy of keeping your interface 'dark' such that you learn to 'shine'. But that's something I ascribe to a personal development journey.

This means things like durability, consistency, atomicity, and isolated side-effects (if any).

This is what Erlang does. A process is isolated, so when it just falls apart, the parent can handle that "gracefully" despite said process literally disintegrated in a critical irreparable way.

It's a bit like designing covert spy networks...