Yup, all of these. Sometimes I look "around" the problem, like, "I found THIS directory but the file 'z.txt' was not in it!" or "Not only could I not find 'z.txt' I could not find THIS directory it was supposed to be in." Check to see that it is really a file, not a directory. "I found 'z.txt' in THIS directory but it was zero bytes in length!"

In terms of "fail early," my larger programs have a section called Pre-Flight Checklist, which looks for files (and that they are files), databases, that the databases have the expected tables and the correct columns, and so on. Are the files sufficiently recent? More or less the expected length? Because this is ETL stuff, it's usually okay to push this stuff up as early as I can.

For Saas products, this plus use structured logging so you don't have to grep-parse log messages when searching your log collectors.

Ie all the meta/log context in a hashmap alongside the error message.

A couple+ years ago my then employer required I take (what amounted to) Security Training 101 for Software Developers. I believe one of the client orgs expected everyone to go through the program.

That said, Ppetty much everything you're suggesting was considered a bad idea (for security). Mainly because the more details you give away, the more a hacker can understand about the underlying system. The more they probe and possibly break things, the more you're showing your cards.

It was then the bland cryptic error msg made perfect sense to me.

Well, everything is depends on context of course.

I'm talking here mostly of user-facing local applications -- like what would be in your mail client's logs, or the logs of a corporate service, where the logs are there for the admin's/dev's use.

Of course if you're sending feedback to a potential attacker things change considerably.

I understand. But I'm going to assume the rule would be. Do X. No exceptions. As you know, doing sec means living with a healthy amount of paranoia. Imagine giving an exception and being wrong.

Sec = better safe than sorry.

I'll also add to make them easy to copy to clipboard in the case of a GUI-based program.

It's easier to search and store in an incident management system.

For developers, maybe. But they need logs, not error messages.

For users they need brief, is it fatal (restart) temporary (try again) or just this part - do something else.

Adding words is unhelpful. More information means less communication.

Yes to all - and also don't include boilerplate text, or at least limit it to the minimum polite for your audience.

So if you must show a stack dump:

- don't put in lots of whitespace - it might look pretty but it makes it harder to read/parse.

- if you're giving the error file:line, don't bother showing the source code. If the source is meaningful to the reader, they've probably got access to the code, or are using an IDE.

One thing I've recently started doing when a file related error happens is to retry the command with strace and see which file the program is trying to access

Also, make sure that sensitive information like user's passwords, emails, credit card numbers etc, is filtered out of the logs and not sent to your servers.