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 <rony.flatsc...@wu.ac.at>
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 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
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
