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 init CLASS
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.
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
