How to suppress stacktraces from Rule-Connect-Java exceptions?
We have a Rule-Connect-Java which returns throws an exception for config issues. For various reasons of design, this could be thrown 1000's of times in a non-prod system.
This is an example where we'd like the caller to decide whether or not to dump the stacktrace.
There's two ways I can see of suppressing this:
- Override activity Rule-Connector-Java.Invoke and change oLog(msg, cause)
- Update our log4j appender to use the pattern
%throwable{short}
Neither of these is ideal, especially the second, which would impact in many places.
There oughtta be a parameter on the Rule-Connect-Java call -- or the ruleform as well -- for the programmer to decide whether to suppress the logs or not.
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Pegasystems Inc.
US
That would be nice. But what kind of exceptions are you referring to? Are they really "Exceptions" or you are using exceptions as part of control flows? (which should be avoided). Currently, Rule-Connector-Java.Invoke captures ActivityTerminationException, PRAppRuntimeException and PRRuntimeException and rethrow them.
BNY Mellon
US
Well, it's kind of specific to our app, and I don't think it matters to this problem.
Basically, it's Java API for querying an outside database. If the user or group is not in the system, the function returns an exception (as opposed to returning an error code).
We could also work around this by making the Java directly in a function, and catching the error on our own, of course.
Does the 'transition' in activity step which 'Connect-Java' does not capture this? i guess by this time you already have error in the log file(?).
For this use case, call a class method using Connect-Java in an activity step and Connect-java call fails with a run time error.
BNY Mellon
US
Indeed, the transition does catch the error, which is what we're using.
But the stacktrace has already been thrown.
Like I said, if we have time, I'd just have the team to rewrite this to call Java directly. I'd be happy to use the macro-ability of activity methods, but only if they can provide us with the same measure of control as in Java.