[tichiian]

There are reasons for not reporting detailed errors to the user.

For websites, security is a big one. Detailed error messages can lead to information exfiltration, exploits, fingerprinting and generally bad things. Long error messages in some network protocols enable amplification attacks.

For general applications, there are commercial reasons. You don't want to enable your users too much, they should be incentivized to buy your pricey platinum premium package after all. Therefore an opaque error message, maybe with some error code but no text and no information, is necessary: The user will need to call support and get the error code decoded and be told in hour-long, tedious and expensive support calls how to fix the error. Actually actionable errors are what makes your company go bankcrupt, especially if you do freemium or OSS+support business models.

[burnte]

While this is true, I don't think you truly missed my point. This is just being pedantic for the sake of it.

[tichiian]

You are right in that the world would be a better place with more useful and actionable error messages.

But:

> How is it not obvious to the point of pain that you need to know WHY something failed, not only that it failed?

This is obvious to everyone, at least after encountering the first few errors. But that makes it the perfect thing to upsell, to milk your existing customers with a pricier plan. One instance is e.g. Microsoft selling access to their customers' logs to those same customers: https://www.theregister.com/2023/07/20/under_cisa_spressures... (they backpedalled after it blew up spectacularly).

No, I don't like it. Yes, I hate those Ferengi. Changing how things are for the better not only requires recognizing the immediate problems but also why the problem is persisted, and who is to blame for it.