Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Populate Text(58) field when rejectMessageOnUnhandledException=true #851

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mgatny
Copy link

@mgatny mgatny commented Aug 2, 2024

Supersedes #667
refs #639

If rejectMessageOnUnhandledException=true and an unhandled exception is thrown from the fromCallback(), include the exception message in the Text(58) field of the resulting Reject or BusinessMessageReject.

@chrjohn chrjohn changed the title Populate Text(58) field when rejectMessageOnUnhandledException=true Populate Text(58) field when rejectMessageOnUnhandledException=true Aug 5, 2024
@chrjohn
Copy link
Member

chrjohn commented Aug 5, 2024

@mgatny thanks for the PR.
The only thing that troubles me is that it might reveal internal information about the application e.g. "Out of memory" or similar. What do you think about adding a prefix like "error: " or "problem: " to the Text field so that users could possibly filter out such messages in their toAdmin() or toApp() callbacks?

@mgatny mgatny force-pushed the add-reason-to-unhandled-exception-reject branch from ca0e9d8 to c635430 Compare September 26, 2024 13:34
If rejectMessageOnUnhandledException=true and an unhandled exception is
thrown from the fromCallback(), include the exception message in the
Text(58) field of the resulting Reject or BusinessMessageReject.
@mgatny mgatny force-pushed the add-reason-to-unhandled-exception-reject branch from c635430 to 7a654ea Compare November 13, 2024 14:44
@chrjohn
Copy link
Member

chrjohn commented Nov 23, 2024

@mgatny any comments on my proposal?
#851 (comment)

Thank you

@mgatny
Copy link
Author

mgatny commented Dec 3, 2024

@chrjohn here's what I'm thinking:

  1. If we add Text(58) to the generated Reject at all, we need an additional boolean SessionSetting that enables this behavior, and defaults to "N". Otherwise, anyone already using RejectMessageOnUnhandledException will be surprised that Text(58) automcatically gets set on Rejects.
  2. Instead of QF/j adding a prefix to the Text(58), what if we recommend this approach:
    a. Set RejectMessageOnUnhandledExceptionSetsTextField=Y (or whatever we call the new boolean setting).
    b. Use a well-known string (i.e. a constant) as the exception message when intentionally throwing an exception to cause a Reject.
    c. In toAdmin/toApp, compare the Text(58) to your well-known string(s).
    d. If it's a match, leave the Text(58) on the message.
    e. Otherwise remove Text(58) from the message.

This would allow users to get exactly what they want in Text(58), but still give them the ability to filter. And it will not change any behavior for anyone already using RejectMessageOnUnhandledException.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants