|
"Bartell, Aaron L. (TC)" wrote: > > Here's my deal. I have the following sub procs which interface with java > methods, and if a java exception is thrown I want to catch it in my > RPGMail_xxxx sub procs, parse it, and relay a more friendly error back to > the calling program. Once I have "caught" the "percolated" error is there a > way to 'un-catch' it so the error continues to percolate up to the next > calling program so it errors out with its MONITOR, and once errored out goes > to look in some additional error sub procs I have setup? Aaron, you could use an ILE condition handler instead of MONITOR - see functions CEEHDLR (enable) and CEEHDLU (disable). With a condition handler, you get control before the exception is handled. In the condition handler, you can "promote" the RNX0301 message to your own say XYZ0301 message (in message file QXYZMSG). A warning that doesn't apply to your current case: It's safe and useful to use a condition handler to do exception logging, or to change the exception (percolate or promote), but it can be unsafe to handle the exception. The reason it can be unsafe is that control resumes at the next MI instruction, not the next RPG instruction - if the exception happens halfway through the generated code for an RPG instruction, the rest of the statement would be done, possibly with bad data.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.