Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
On 14.08.2022 15:05, Rick McGuire wrote: On Sun, Aug 14, 2022 at 8:17 AM Rony G. Flatscher wrote: On 14.08.2022 13:41, Rick McGuire wrote: > - The method NativeActivation::checkConditions() is where the raised exceptions are processed when > your external routine returns. Understanding why that code is not raising the exception on the > calling Rexx code would be helpful. The conditionObj NativeActivation::checkConditions() is NULL right before returning. That would suggest you are using the wrong context to raise the exception, because the one you used was returning true for CheckCondition(). CheckCondition() just checks the value of the conditionObj variable. Added debug output in native code. "root_RII" is the (primodal) Rexx instance that is globally available. Also the context gets shown its threadContext and threadContext's instance. Here the relevant ouput: --->hi from test.rex j4: org.rexxla.bsf.engines.rexx.RexxProxy@6ae40994 *** BSF() 1, tid=[24300]/countBSF=[132], BSF(): root_RII=[028AB994F3A0] tid=[24300] | context=[00E57790CE38] ->rtc=[028AB994EDF8] ->instance=[028AB994F3A0] condition=[0]: BEFORE calling Java --->) BSF(): root_RII=[028AB994F3A0] tid=[24300] | context=[00E57790CE38] ->rtc=[028AB994EDF8] ->instance=[028AB994F3A0] context->CheckCondition=[0] context->CheckCondition=[1] jenv->ExceptionCheck=[-858993460]: AFTER calling Java. <-- *** *** DEBUG_BSF_FUNCTION: BSF() 5 - <==> (AFTER -> CallObjectMethod(), tid=[24300]/countBSF=[132], j_returnValue=[] ...) *** *** DEBUG_BSF_FUNCTION: BSF() 5b: Java exception, now: (RgfCreateRexxSyntaxConditionWithJavaThrowable()) *** *** DEBUG_BSF_FUNCTION: BSF() 5c: about to return with NULL: context->CheckCondition()=1 BSF(): root_RII=[028AB994F3A0] tid=[24300] | context=[00E57790CE38] ->rtc=[028AB994EDF8] ->instance=[028AB994F3A0] context->CheckCondition=[1] context->CheckCondition=[1]: Java threw an exception we did a CreateException(), before returning. <-- /-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\ res: RESULT :( :( :( we never should arrive here in case of a pending exception! <=== <== <= \-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/\-/ ---rony ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
On Sun, Aug 14, 2022 at 8:17 AM Rony G. Flatscher wrote: > On 14.08.2022 13:41, Rick McGuire wrote: > > - The method NativeActivation::checkConditions() is where the raised > exceptions are processed when > > your external routine returns. Understanding why that code is not > raising the exception on the > > calling Rexx code would be helpful. > > The conditionObj NativeActivation::checkConditions() is NULL right before > returning. > That would suggest you are using the wrong context to raise the exception, because the one you used was returning true for CheckCondition(). CheckCondition() just checks the value of the conditionObj variable. Rick > > ---rony > > > > > ___ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
On 14.08.2022 13:41, Rick McGuire wrote: - The method NativeActivation::checkConditions() is where the raised exceptions are processed when your external routine returns. Understanding why that code is not raising the exception on the calling Rexx code would be helpful. The conditionObj NativeActivation::checkConditions() is NULL right before returning. ---rony ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
On 14.08.2022 13:41, Rick McGuire wrote:
One question and a couple of suggestions.
- Is the AttachThread() being done on the same instance as the originating rexx code where the
call on syntax was made or a different instance.
The same instance.
- The method NativeActivation::checkConditions() is where the raised exceptions are processed when
your external routine returns. Understanding why that code is not raising the exception on the
calling Rexx code would be helpful.
- This might be easier to debug if you can take Java completely out of the picture. That is, have
an external call that does an AttachThread(), does a SendMessage(), does a DetachThread(), then
does a RaiseException() with the call context. I suspect you'll probably see the same problem, and
that simple type of scenario would be much easier to debug.
Tried to come up with such a test case but have not been successful so far (those attempts caused
the posting about ThrowException).
---rony
On Sun, Aug 14, 2022 at 7:24 AM Rony G. Flatscher
wrote:
Sorry, one thing is wrong in my synopsis (over the past days too many
different test cases and
attempts): the call to the Java side in this case is not carried out via
the unknown method
but directly with invoking the native routine BSF.
---
The last thing I tried was making sure that in the native routine that
creates the exception
and carries out RaiseException1() that it would use the RexxCallContext
everywhere (and not
use RexxCallContext-threadContext which should work anyway). It did not
change this observation.
The use of SetContextVariable() in the native routine that creates the
exception works and the
variables are available upon return to the BSF unknown method.
In the meantime I added a native method BsfCheckCondition() and calling it
immediately upon
return to the Rexx side returns .false/0.
---rony
On 14.08.2022 12:47, Rony G. Flatscher wrote:
O.K. before trying one more thing "in the dark" here a synopsis:
* all calls are carried out on the same thread (no multithreading)
* Rexx starts, using BSF4ooRexx Java gets demand loaded, the native code
stores the
primodal Rexx instance ("ri")
* a Rexx program sends a message to a Java object (a BSF instance)
* the BSF unknown method defines a 'signal on syntax' condition handler
and sets up and
carries out the call to the native routine BSF()
o the native routine BSF() sets up and carries out the call into Java
o the Java method in this use case will cause a Rexx object to be
sent a message, in
the course the native code
+ ri->AttachThread(), sets up and carries out the call into Rexx
+ a Rexx condition occurs causing a Java Throwable to be created
using the Rexx
condition information
+ ri->DetachThread()
+ the Java Throwable gets thrown, control returns to Java
o the Java method returns to native code with the thrown Java
Throwable active
(jenv->ExceptionCheck() returns true)
o the native code creates a Rexx exception using data from the Java
Throwable, adds the
Java Throwable object to additional() to allow access from Rexx to
it, then does a
context->RaiseException1() wich is active (tested with
RexxCondition() immediately
before returning from native code to Rexx); here to illustrate that
section, both
tests (using the RexxCallContext and its contained threadContext)
return true:
#if defined (DEBUG_BSF_FUNCTION)
fprintf(stderr, "*** *** DEBUG_BSF_FUNCTION: BSF() 5c: about to return with NULL:
context->CheckCondition()=%d | context->threadContext->CheckCondition()=%d\n",
context->CheckCondition(), context->threadContext->CheckCondition());
fflush(stderr);
#endif
return NULLOBJECT;
o a return NULLOBJECT in native code returns to the Rexx caller (the
unknown method)
* the BSF unknown method does not transfer control to the syntax label,
the condition has
been cleared between returning from native code and transferring
control back to the BSF
unknown method
---rony
On 12.08.2022 16:00, Rony G. Flatscher wrote:
On 11.08.2022 21:13, Rony G. Flatscher wrote:
In an ooRexx package there are the following statements:
... cut ...
::ROUTINE xBSF PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF
"
... cut ...
::CLASS BSF
::ATTRIBUTE rBSF CLASS
::METHOD initCLASS
expose rBSF
rBSF =.routines["XBSF"] -- fetch and store routine object
... cut ...
::METHOD unknown UNGUARDED
... cut ...
signal on syntax
self~class~rBSF~callWith(arr)
Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
One question and a couple of suggestions.
- Is the AttachThread() being done on the same instance as the originating
rexx code where the call on syntax was made or a different instance.
- The method NativeActivation::checkConditions() is where the raised
exceptions are processed when your external routine returns. Understanding
why that code is not raising the exception on the calling Rexx code would
be helpful.
- This might be easier to debug if you can take Java completely out of the
picture. That is, have an external call that does an AttachThread(), does a
SendMessage(), does a DetachThread(), then does a RaiseException() with the
call context. I suspect you'll probably see the same problem, and that
simple type of scenario would be much easier to debug.
Rick
On Sun, Aug 14, 2022 at 7:24 AM Rony G. Flatscher
wrote:
> Sorry, one thing is wrong in my synopsis (over the past days too many
> different test cases and attempts): the call to the Java side in this case
> is not carried out via the unknown method but directly with invoking the
> native routine BSF.
>
> ---
>
> The last thing I tried was making sure that in the native routine that
> creates the exception and carries out RaiseException1() that it would use
> the RexxCallContext everywhere (and not use RexxCallContext-threadContext
> which should work anyway). It did not change this observation.
>
> The use of SetContextVariable() in the native routine that creates the
> exception works and the variables are available upon return to the BSF
> unknown method.
>
> In the meantime I added a native method BsfCheckCondition() and calling it
> immediately upon return to the Rexx side returns .false/0.
>
> ---rony
> On 14.08.2022 12:47, Rony G. Flatscher wrote:
>
> O.K. before trying one more thing "in the dark" here a synopsis:
>
>- all calls are carried out on the same thread (no multithreading)
>- Rexx starts, using BSF4ooRexx Java gets demand loaded, the native
>code stores the primodal Rexx instance ("ri")
>- a Rexx program sends a message to a Java object (a BSF instance)
>- the BSF unknown method defines a 'signal on syntax' condition
>handler and sets up and carries out the call to the native routine BSF()
>- the native routine BSF() sets up and carries out the call into Java
> - the Java method in this use case will cause a Rexx object to be
> sent a message, in the course the native code
> - ri->AttachThread(), sets up and carries out the call into Rexx
> - a Rexx condition occurs causing a Java Throwable to be created
> using the Rexx condition information
> - ri->DetachThread()
> - the Java Throwable gets thrown, control returns to Java
> - the Java method returns to native code with the thrown Java
> Throwable active (jenv->ExceptionCheck() returns true)
> - the native code creates a Rexx exception using data from the Java
> Throwable, adds the Java Throwable object to additional() to allow
> access
> from Rexx to it, then does a context->RaiseException1() wich is active
> (tested with RexxCondition() immediately before returning from native
> code
> to Rexx); here to illustrate that section, both tests (using the
> RexxCallContext and its contained threadContext) return true:
>
> #if defined (DEBUG_BSF_FUNCTION)
> fprintf(stderr, "*** *** DEBUG_BSF_FUNCTION: BSF() 5c: about to
> return with NULL: context->CheckCondition()=%d |
> context->threadContext->CheckCondition()=%d\n", context->CheckCondition(),
> context->threadContext->CheckCondition());
> fflush(stderr);
> #endif
> return NULLOBJECT;
>
> - a return NULLOBJECT in native code returns to the Rexx caller
> (the unknown method)
> - the BSF unknown method does not transfer control to the syntax
>label, the condition has been cleared between returning from native code
>and transferring control back to the BSF unknown method
>
> ---rony
>
>
>
> On 12.08.2022 16:00, Rony G. Flatscher wrote:
>
> On 11.08.2022 21:13, Rony G. Flatscher wrote:
>
> In an ooRexx package there are the following statements:
>
> ... cut ...
>
> ::ROUTINE xBSF PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF
> "
>
> ... cut ...
>
> ::CLASS BSF
>
> ::ATTRIBUTE rBSF CLASS
>
> ::METHOD initCLASS
> expose rBSF
> rBSF =.routines["XBSF"] -- fetch and store routine object
> ... cut ...
>
> ::METHOD unknown UNGUARDED
> ... cut ...
> signal on syntax
>
> self~class~rBSF~callWith(arr) -- invoke external routine
> return bsf.wrap(result)
> syntax:
> ... cut ...
> co=condition('o')
> call ppJavaExceptionChain(co,.true)
> raise propagate
>
> So a native routine BSF() gets defined and named in the package as the
> public routine xBSF which in the class constructor for the class BSF gets
> fetched from the .routines directory and stored as a routine
Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
Sorry, one thing is wrong in my synopsis (over the past days too many different test cases and
attempts): the call to the Java side in this case is not carried out via the unknown method but
directly with invoking the native routine BSF.
---
The last thing I tried was making sure that in the native routine that creates the exception and
carries out RaiseException1() that it would use the RexxCallContext everywhere (and not use
RexxCallContext-threadContext which should work anyway). It did not change this observation.
The use of SetContextVariable() in the native routine that creates the exception works and the
variables are available upon return to the BSF unknown method.
In the meantime I added a native method BsfCheckCondition() and calling it immediately upon return
to the Rexx side returns .false/0.
---rony
On 14.08.2022 12:47, Rony G. Flatscher wrote:
O.K. before trying one more thing "in the dark" here a synopsis:
* all calls are carried out on the same thread (no multithreading)
* Rexx starts, using BSF4ooRexx Java gets demand loaded, the native code
stores the primodal
Rexx instance ("ri")
* a Rexx program sends a message to a Java object (a BSF instance)
* the BSF unknown method defines a 'signal on syntax' condition handler and
sets up and carries
out the call to the native routine BSF()
o the native routine BSF() sets up and carries out the call into Java
o the Java method in this use case will cause a Rexx object to be sent a
message, in the
course the native code
+ ri->AttachThread(), sets up and carries out the call into Rexx
+ a Rexx condition occurs causing a Java Throwable to be created
using the Rexx
condition information
+ ri->DetachThread()
+ the Java Throwable gets thrown, control returns to Java
o the Java method returns to native code with the thrown Java Throwable
active
(jenv->ExceptionCheck() returns true)
o the native code creates a Rexx exception using data from the Java
Throwable, adds the Java
Throwable object to additional() to allow access from Rexx to it, then
does a
context->RaiseException1() wich is active (tested with RexxCondition()
immediately before
returning from native code to Rexx); here to illustrate that section,
both tests (using
the RexxCallContext and its contained threadContext) return true:
#if defined (DEBUG_BSF_FUNCTION)
fprintf(stderr, "*** *** DEBUG_BSF_FUNCTION: BSF() 5c: about to return with NULL:
context->CheckCondition()=%d | context->threadContext->CheckCondition()=%d\n",
context->CheckCondition(), context->threadContext->CheckCondition());
fflush(stderr);
#endif
return NULLOBJECT;
o a return NULLOBJECT in native code returns to the Rexx caller (the
unknown method)
* the BSF unknown method does not transfer control to the syntax label, the
condition has been
cleared between returning from native code and transferring control back to
the BSF unknown
method
---rony
On 12.08.2022 16:00, Rony G. Flatscher wrote:
On 11.08.2022 21:13, Rony G. Flatscher wrote:
In an ooRexx package there are the following statements:
... cut ...
::ROUTINE xBSF PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF
"
... cut ...
::CLASS BSF
::ATTRIBUTE rBSF CLASS
::METHOD initCLASS
expose rBSF
rBSF =.routines["XBSF"] -- fetch and store routine object
... cut ...
::METHOD unknown UNGUARDED
... cut ...
signal on syntax
self~class~rBSF~callWith(arr) -- invoke external routine
return bsf.wrap(result)
syntax:
... cut ...
co=condition('o')
call ppJavaExceptionChain(co,.true)
raise propagate
So a native routine BSF() gets defined and named in the package as the public routine xBSF which
in the class constructor for the class BSF gets fetched from the .routines directory and stored
as a routine object with a class attribute named rBSF. In the BSF instance method unknown this
routine object gets fetched from the class attribute and using CALLWITH it gets invoked
supplying a Rexx array with arguments.
The native routine BSF() in this case may raise an exception using
rtc->RaiseException(Rexx_Error_Incorrect_call_user_defined, ra);
However, upon return from the native routine BSF the raised exception does not get trapped in
the ooRexx unknown method such that the code after the syntax label does not get executed.
Doing instead
res=xbsf("invoke", j4, "sendMessageScoped", "abc", "1", "2", "3")
traps the rtc->RaiseException() condition ("abc" in this test will not yield a
Rexx class object).
Sorry, the above statement is not equivalent, it needs to be rewritten as
jArgs=bsf.createJavaArrayOf("java.lang.Object", 1, 2, 3) -- with or without
quotes
Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
O.K. before trying one more thing "in the dark" here a synopsis:
* all calls are carried out on the same thread (no multithreading)
* Rexx starts, using BSF4ooRexx Java gets demand loaded, the native code
stores the primodal Rexx
instance ("ri")
* a Rexx program sends a message to a Java object (a BSF instance)
* the BSF unknown method defines a 'signal on syntax' condition handler and
sets up and carries
out the call to the native routine BSF()
o the native routine BSF() sets up and carries out the call into Java
o the Java method in this use case will cause a Rexx object to be sent a
message, in the
course the native code
+ ri->AttachThread(), sets up and carries out the call into Rexx
+ a Rexx condition occurs causing a Java Throwable to be created using
the Rexx condition
information
+ ri->DetachThread()
+ the Java Throwable gets thrown, control returns to Java
o the Java method returns to native code with the thrown Java Throwable
active
(jenv->ExceptionCheck() returns true)
o the native code creates a Rexx exception using data from the Java
Throwable, adds the Java
Throwable object to additional() to allow access from Rexx to it, then
does a
context->RaiseException1() wich is active (tested with RexxCondition()
immediately before
returning from native code to Rexx); here to illustrate that section,
both tests (using the
RexxCallContext and its contained threadContext) return true:
#if defined (DEBUG_BSF_FUNCTION)
fprintf(stderr, "*** *** DEBUG_BSF_FUNCTION: BSF() 5c: about to return with NULL:
context->CheckCondition()=%d | context->threadContext->CheckCondition()=%d\n",
context->CheckCondition(), context->threadContext->CheckCondition());
fflush(stderr);
#endif
return NULLOBJECT;
o a return NULLOBJECT in native code returns to the Rexx caller (the
unknown method)
* the BSF unknown method does not transfer control to the syntax label, the
condition has been
cleared between returning from native code and transferring control back to
the BSF unknown method
---rony
On 12.08.2022 16:00, Rony G. Flatscher wrote:
On 11.08.2022 21:13, Rony G. Flatscher wrote:
In an ooRexx package there are the following statements:
... cut ...
::ROUTINE xBSF PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF
"
... cut ...
::CLASS BSF
::ATTRIBUTE rBSF CLASS
::METHOD initCLASS
expose rBSF
rBSF =.routines["XBSF"] -- fetch and store routine object
... cut ...
::METHOD unknown UNGUARDED
... cut ...
signal on syntax
self~class~rBSF~callWith(arr) -- invoke external routine
return bsf.wrap(result)
syntax:
... cut ...
co=condition('o')
call ppJavaExceptionChain(co,.true)
raise propagate
So a native routine BSF() gets defined and named in the package as the public routine xBSF which
in the class constructor for the class BSF gets fetched from the .routines directory and stored
as a routine object with a class attribute named rBSF. In the BSF instance method unknown this
routine object gets fetched from the class attribute and using CALLWITH it gets invoked supplying
a Rexx array with arguments.
The native routine BSF() in this case may raise an exception using
rtc->RaiseException(Rexx_Error_Incorrect_call_user_defined, ra);
However, upon return from the native routine BSF the raised exception does not get trapped in the
ooRexx unknown method such that the code after the syntax label does not get executed.
Doing instead
res=xbsf("invoke", j4, "sendMessageScoped", "abc", "1", "2", "3")
traps the rtc->RaiseException() condition ("abc" in this test will not yield a
Rexx class object).
Sorry, the above statement is not equivalent, it needs to be rewritten as
jArgs=bsf.createJavaArrayOf("java.lang.Object", 1, 2, 3) -- with or without
quotes
res=xbsf("invoke", j4, "sendmessageScoped", "info", "abc", jArgs)
it then behaves as within the unknown method. In this variant a "Error 44.1: No data returned
from function "XBSF"." error will get raised.
Here the version that is equivalent to the one in the unknown method and does not trigger the
syntax handler on the Rexx code either:
call xbsf "invoke", j4, "sendmessageScoped", "info", "abc", jArgs
context->CheckCondition() immediately before returning to the calling Rexx program will be true in
the native code however the syntax handler does not get triggered.
For debugging purposes the native code defines context variables
[context->SetContextVariable("BSF_ERROR_MESSAGE",msg) and
context->SetContextVariable("BSF_ERROR_OBJECT",javaThrowable)] which are available and can be used
from the caller's context (which the test program does).
Tried to come up with a stand alone example that would
Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
> > call ppJavaExceptionChain(co,.true) > > This look suspicious to me and may be unintended. Here ppJavaExceptionChain is called with a single argument, an Array of (co, .true) I think it's a bit unfortunate that we allow this kind of syntax (as it's almost always unintended). ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
On 11.08.2022 21:13, Rony G. Flatscher wrote:
In an ooRexx package there are the following statements:
... cut ...
::ROUTINE xBSF PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF
"
... cut ...
::CLASS BSF
::ATTRIBUTE rBSF CLASS
::METHOD initCLASS
expose rBSF
rBSF =.routines["XBSF"] -- fetch and store routine object
... cut ...
::METHOD unknown UNGUARDED
... cut ...
signal on syntax
self~class~rBSF~callWith(arr) -- invoke external routine
return bsf.wrap(result)
syntax:
... cut ...
co=condition('o')
call ppJavaExceptionChain(co,.true)
raise propagate
So a native routine BSF() gets defined and named in the package as the public routine xBSF which
in the class constructor for the class BSF gets fetched from the .routines directory and stored as
a routine object with a class attribute named rBSF. In the BSF instance method unknown this
routine object gets fetched from the class attribute and using CALLWITH it gets invoked supplying
a Rexx array with arguments.
The native routine BSF() in this case may raise an exception using
rtc->RaiseException(Rexx_Error_Incorrect_call_user_defined, ra);
However, upon return from the native routine BSF the raised exception does not get trapped in the
ooRexx unknown method such that the code after the syntax label does not get executed.
Doing instead
res=xbsf("invoke", j4, "sendMessageScoped", "abc", "1", "2", "3")
traps the rtc->RaiseException() condition ("abc" in this test will not yield a
Rexx class object).
Sorry, the above statement is not equivalent, it needs to be rewritten as
jArgs=bsf.createJavaArrayOf("java.lang.Object", 1, 2, 3) -- with or without
quotes
res=xbsf("invoke", j4, "sendmessageScoped", "info", "abc", jArgs)
it then behaves as within the unknown method. In this variant a "Error 44.1: No data returned from
function "XBSF"." error will get raised.
Here the version that is equivalent to the one in the unknown method and does not trigger the syntax
handler on the Rexx code either:
call xbsf "invoke", j4, "sendmessageScoped", "info", "abc", jArgs
context->CheckCondition() immediately before returning to the calling Rexx program will be true in
the native code however the syntax handler does not get triggered.
For debugging purposes the native code defines context variables
[context->SetContextVariable("BSF_ERROR_MESSAGE",msg) and
context->SetContextVariable("BSF_ERROR_OBJECT",javaThrowable)] which are available and can be used
from the caller's context (which the test program does).
Tried to come up with a stand alone example that would exhibit this behaviour,
so far without success.
If there is anything I could do to become able to shed more light into this,
please let me know.
---rony
P.S.: Here the Rexx test program:
parse source s; say s
parse version v; say v
say .bsf4rexx~display.version
call test_plain_rexx
call test_rexx_proxy
::requires BSF.CLS
::class class_level1
::method info
return "info<< CLASS_LEVEL1 >>info <>"
::class class_level2 mixinclass class_level1
::method info
return "info<< CLASS_LEVEL2 >>info <>"
::class class_level3 mixinclass class_level1
::method info
return "info<< CLASS_LEVEL3 >>info <>"
::class class_level4 subclass class_level2 inherit class_level3
::method info
return "info<< CLASS_LEVEL4 >>info <>"
::routine test_plain_rexx
say .context~name":"
say
t4=.class_level4~new
say "t4~info:" t4~info
say "t4~info:" t4~info(1,2,3)
say "t4~info:class_level3:" t4~info:.class_level3
say "t4~info:class_level2:" t4~info:.class_level2
say "t4~info:class_level1:" t4~info:.class_level1
say "-"~copies(79)
::routine test_rexx_proxy -- via Java
say .context~name":"
say
t4=.class_level4~new
say "t4~info:" t4~info
j4=BsfCreateRexxProxy(t4) -- will box the Rexx object in a Java object
(of type RexxProxy which allows sending messages to the boxed Rexx object)
-- now send the boxed Rexx object various messages from the Java side
say "j4:" pp(j4) "j4~sendMessage0('info'):" j4~sendMessage0('info')
say "j4:" pp(j4) "j4~sendMessage3('info',1,2,3):"
j4~sendMessage3('info',1,2,3)
say "-"~copies(79)
say "j4:" pp(j4) "j4~sendMessageScoped('info',.class_level3,.nil):"
j4~sendMessageScoped('info', .class_level3, .nil)
say "j4:" pp(j4) "j4~sendMessageScoped('info',.class_level2,.nil):"
j4~sendMessageScoped('info', .class_level2, .nil)
say "j4:" pp(j4) "j4~sendMessageScoped('info',.class_level1,.nil):"
j4~sendMessageScoped('info', .class_level1, .nil)
jArgs=bsf.createJavaArrayOf("java.lang.Object", 1, 2, 3) -- arguments
must be boxed as a Java array object
say "j4:" pp(j4)
[Oorexx-devel] Observation with .routine's callwith and threadContext->RaiseException(...)
In an ooRexx package there are the following statements:
... cut ...
::ROUTINE xBSF PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF
"
... cut ...
::CLASS BSF
::ATTRIBUTE rBSF CLASS
::METHOD initCLASS
expose rBSF
rBSF =.routines["XBSF"] -- fetch and store routine object
... cut ...
::METHOD unknown UNGUARDED
... cut ...
signal on syntax
self~class~rBSF~callWith(arr) -- invoke external routine
return bsf.wrap(result)
syntax:
... cut ...
co=condition('o')
call ppJavaExceptionChain(co,.true)
raise propagate
So a native routine BSF() gets defined and named in the package as the public routine xBSF which in
the class constructor for the class BSF gets fetched from the .routines directory and stored as a
routine object with a class attribute named rBSF. In the BSF instance method unknown this routine
object gets fetched from the class attribute and using CALLWITH it gets invoked supplying a Rexx
array with arguments.
The native routine BSF() in this case may raise an exception using
rtc->RaiseException(Rexx_Error_Incorrect_call_user_defined, ra);
However, upon return from the native routine BSF the raised exception does not get trapped in the
ooRexx unknown method such that the code after the syntax label does not get executed.
Doing instead
res=xbsf("invoke", j4, "sendMessageScoped", "abc", "1", "2", "3")
traps the rtc->RaiseException() condition ("abc" in this test will not yield a
Rexx class object).
---rony
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
