[monkpit]

This is the root of the problem, I think. Especially in JavaScript with the blanket ‘catch’ mechanism and no real good way to have any idea of what exceptions could have even been thrown in the current context.

Obviously the dev will have some idea of which error could have occurred (hence the use of ‘catch’ at all), but it’s not straightforward to enumerate all possible exceptions in that moment, and reason about some subset that should be human-readable, and then come up with some sort of instructions about how to fix the problem.

Maybe that’s the point of the root comment - the exceptions that the dev is trying to catch and prevent from affecting the user should have those human-readable descriptions. And the rest should be silently logged?

But that still just leads to the generic “Well, this is awkward…” errors that you see these days.

It’s a tough topic, and even having the insight of (for example) Java’s ‘throws’ still doesn’t mean the developer explicitly understands the state of the application when those exceptions are thrown (in order to provide some sort of useful message to the user).