Please please please improve error reporting

[jamie]

The system often feels like a bit of a black box — we frequently see vague messages like “an error has happened” without any clear context. This makes it hard to understand what’s actually gone wrong, leaving us digging through logs and even modifying core code just to get answers.

Improving transparency around errors would go a long way. After all, “security through obscurity” isn’t really an effective strategy — clarity and proper error handling help everyone.


thanks yuri

[yuri]

I don't understand the problem. We have logs. We have the ability to see log messages in the admin UI (disabled by default). What we could do more.

[yuri]

We could print error details in the browser console when the system is in the developer mode. But it's not quite different than just checking the log via the admin UI.

[yuri]

Printing backtrace to log usually enough for complex cases.

[shalmaxb]

Hi @yuri,
what is printing backtrace? Did I miss something? I would appreciate an explanation. Thank you in advance.

[jamie]

Yes, that’s exactly it — we need feedback in the browser that actually explains what went wrong.

Not everything gets logged because many issues aren’t truly fatal errors. But that’s all the more reason to provide helpful error messages at every stage — especially in production. A vague “error” message leaves us with nothing to go on. It forces us to turn on debug mode or try to recreate the problem from scratch, when instead, if the browser reported the real issue, a user could simply send me a screenshot and I’d immediately know what needs fixing.

If the idea is to hide errors for security reasons, “security through obscurity” isn’t effective — attackers can usually work around that. And if it’s for aesthetic reasons, I’d argue that nothing is more elegant than a system that actually works. A clear, useful error message is far better than a mysterious one that leaves everyone guessing.

[jamie]

Printing backtrace to log usually enough for complex cases.

how do i do that?

[yuri]

https://docs.espocrm.com/administration/log/

'printTrace' => true,

[yuri]

I have the different view on it. On production, there should be printed almost nothing for an end user unless it's an expected error like validation. If an error happens, it indicates that something is wrong and must be fixed. Checking the logs should not be a big deal. It's not necessarily log files – you can configure a log handler to print it anywhere. It's worth for production.

[jamie]

Let me give you an example.

A user ran into an error yesterday and later emailed me about it, but only with a vague description of what happened. I can’t reliably recreate it. So how do I figure out what actually went wrong? The log files contain hundreds (sometimes thousands) of entries I’d need to dig through, and there’s no guarantee that this specific error was even logged. That leaves me stuck — and worse, it can make your system look like it’s intentionally hiding errors and making support harder than it needs to be. If that happens too often, companies may naturally look for alternatives that respect their users enough to clearly show what went wrong instead of obscuring it.

Keep in mind, your product is mostly used inside large organizations, not by the general public. Many of these companies have IT teams whose role is to support your software. It makes a huge difference if the system helps them do that job, rather than making it harder.

If detailed errors in production are a concern, at the very least they should be available in debug mode. As I mentioned before, not every issue makes it into the logs — but those issues still need fixing. A little consideration for the IT staff who have to investigate these problems goes a long way. Just tell us what went wrong so we can get it resolved quickly.

[yuri]

It's just a normal practice not to display error details to end users.

> alternatives that respect their users enough

That's harsh.

> and there’s no guarantee that this specific error was even logged

If it's not logged, that would mean that no details can be printed to the user also. It means the error happened non on the application error.

[yuri]

If the log contains hundreds of errors it means that the system has problems that needs to be addressed. There should not be errors in your log.

If you mean messages of NOTICE, DEBUG levels, you can filter them out when viewing the log from the UI.

[Kharg]

Why not adding a “Correlation ID” or a “Trace ID” to the logs and show an error message or a message in the browser console so that the error triggered can be traced back with a screenshot?

or maybe just a simple ID so that it can be filtered from the admin logs UI entity.

[yuri]

It's viable. It will make it easier to match the error in the log with the error a user reported.

Though, it's not that crucial in the normal scenario. If there are hundreds of errors in the log, it the signal to fix them all first.

[jamie]

I want to be upfront — I’m using AI to help phrase this constructively, but the underlying point is important. If user needs aren’t listened to, and the response is simply “that’s the way it’s done,” people will naturally start looking at other options that are easier to use and backed by more responsive support.

In enterprise software, it’s normal — and expected — to display error details to users. This isn’t a WordPress site for the general public; it’s business-critical software being used by professionals. We depend on your product to work with us, not against us.

At the moment, the only option we have is to sift through massive log files in the hope of spotting something useful. Suggesting we just “log more” doesn’t help — it only creates more noise, making it even harder to find the real issue. With hundreds of users, it’s often just one person who encounters an error. Or during setup, I’ll get a vague message that provides no meaningful information in the logs. That’s not a practical way to handle enterprise-level support.

So I have to ask: why not make the system more user-friendly? The current approach feels rigid and inflexible, which doesn’t align with the needs of large organizations — the very customers most likely to invest in your product.

Please, take into account what your users are asking for rather than defaulting to “we don’t do that.” It’s my role to recommend whether we continue with your product or move to an alternative, and right now it feels like valid feedback is being dismissed. I’m even resorting to AI just to ensure my messages come across as polite, yet the responses I get back are often very brief and don’t show much consideration. I hope you can take a step back and see this from my perspective.

[jamie]

Why not adding a “Correlation ID” or a “Trace ID” to the logs and show an error message or a message in the browser console so that the error triggered can be traced back with a screenshot?

or maybe just a simple ID so that it can be filtered from the admin logs UI entity.

great idea but why not just report error to browser?

[yuri]

Speaking about alternatives, in most cases there will be just no feedback from developers.

I has a strong opinion that error details should not be printed to the user. In developer mode it's fine, but you speak about the production.

[jamie]

With enterprise-level applications, customers always expect support — sometimes directly from developers, but more often from a dedicated support team that helps balance customer needs with the product vision.

Your strong opinion on this is one thing, but I have to be honest: the current approach feels degrading to users and, at times, dismissive of their intelligence.

At the very least, could you make this available in development mode, or provide an option to enable it for those of us who have a different perspective? That way, everyone gets what they need without forcing a one-size-fits-all approach.

[jamie]

Just to recap: your suggestion for not displaying errors was to “log more.” But when I raised the issue that the logs were becoming too large, the response was that they should be “shorter.” Can you see how that ends up feeling contradictory and not very helpful?