Separate Exception Messages from Error Log messages

On our radar

The discussion around the "string truncated" error brought this up... we need to be able to throw an exception in a manner where there are two messages: one that gets logged in Error Log, and one that goes onto the stack as Exception Message. Reason is that sometimes we need to throw something where the proper message for debugging purposes may contain sensitive or in-depth technical information (like database details) that should only go to the error log and never go to the screen, but we want a friendly message to go to the screen.


Created on 9 Jun 2017
Comments (8)


Merged this idea with 'Security - SQL statements - Feedback message' (created on 2018-01-17 10:30:51 by Miguel Sousa)

Outsystems should prevent sending any kind of SQL statements / scripts to the browser as a feedback when an error occurs.

Merged from 'Security - SQL statements - Feedback message' (idea created on 2018-01-17 10:30:51 by Miguel Sousa), on 2018-01-18 03:46:04 by Justin James

The fix for this is to have a private & public message in the Exception. I know there is a similar idea out there, let me try to merge... I suspect I posted it a few years ago...


Merged from 'Security - SQL statements - Feedback message' (idea created on 2018-01-17 10:30:51 by Miguel Sousa), on 2018-01-18 03:46:04 by Justin James
Merged this idea with 'Better default/auto-generated Screen Action error handling' (created on 2018-04-21 13:34:33 by Caio Santana)

By default, Screen Actions add a single Error Handler for All Exceptions which displays the exception message directly onto a Feedback Message balloon.

Here's the thing: interal errors (eg. DBMS timeouts, SQL errors, table constraints, ...) may be displayed to the end user this way. The worst scenario happens when a SQL error occurs, which discloses the query onto the screen.

In order to avoid this, we have been painstakingly changing all generated Error Handlers from "All Exceptions" to "User Exceptions" (which we have control over the generated exception message and thus can be shown to the end user without a problem), and then adding a second Error Handler for "All Exceptions" which displays a generic "An internal error occurred." onto the Feedback Message.

We also set the "Log Error" parameter in the User Exception Error Handler from Yes to No so that validation messages (eg. "Invalid username/password") do not pollute Service Center.

Given the good practice of not disclosing technical information to the end user, and also since the error handling mechanism is auto-generated for screen actions, I think both error handlers should be generated by default.

save image

Merged from 'Better default/auto-generated Screen Action error handling' (idea created on 2018-04-21 13:34:33 by Caio Santana), on 2018-04-22 14:32:49 by Justin James

I don't think my idea was related to this idea to the point of having a merger...

I suggested making a simple addition to the auto-generated error handler in Screen Actions, not a separate way of logging exception messages.

They are not *exactly* the same idea, true, but I felt that they were very similar, and are trying to achieve the same goals (not sending DB and other sensitive error messages to the screen, but providing a way to log those messages and get a different message to the screen).

Unfortunately, there's no good way to UN-merge. :(