"Something went wrong, please try again later :)" is cheap (try { } catch () { print "Something went wrong" })

"TypeError: Cannot read property 'submit' of null" is cheap (just render whatever error you get).

Anything else is expensive, and probably doesn't gain you anything.

Those are two ends of the spectrum of how to handle unknown errors, but ignore the other axis: known errors. The UI displaying a red text field saying "field whatever is required to continue" is just as much an error message, but it's clearly actionable. There are lots of reasonably actionable error messages in all varieties of UIs for expected error cases.

I don't know that there's a lot of useful middle ground between your two examples though. By definition, a UI can't really give actionable advice on how to fix an error that it isn't programmed to expect.

Yeah this problem is a little more complicated than what I mentioned. By all means map known errors, but does the fallback really need to be "something went wrong?"

It was a bit of a rhetorical statement (or at least in my mind it was). Like how about "Something went wrong (see details)" or something to that effect?

In my work experience some people are really dogmatic about the idea of not showing any sort of error messages to users whatsoever.

In my work experience, users will complain about any sort of message. We recently got a request to change a message of "OK" to something more detailed. What more do you want than a message telling you that the thing you were trying to do succeeded?

So I'm very sympathetic to people arguing against showing error messages.

Yes, the user should see the former, and the application should log the latter.

The user probably can't do anything about a null reference, so there's not a lot of benefit in providing this level of detail, and for most users it obscures the bigger point that "something went wrong."