Closed jgomer2001 closed 11 months ago
After many rounds of playing with transpiled code I discovered the situation is presented whenever a (flow) function terminates execution abruptly, be it caused by a Java Call
that threw exception or by any other error, e.g. accessing a member of an inexisting variable
Even Java Call
s that have exception handling (like var | E = Call ...
) provoke the undesired serialization when the exception is caught!
Serialization of arbitrary variables is already problematic. It is necessary to avoid serialization of unnecessary variables at all cost. A solution has to address the following:
Call
s are always "successful". This can be done by wrapping the original Java invocation with a Java try-catch and returning a pair with the result of the invocation plus the exception, if any. This way, Java exceptions are not handled at Javascript levelWith the two points above, functions will always return a definite value. To implement the solution (ie. no throws) a transpiler rework is required
When a flow A calls another B, if B crashes and A catches the crash, an undesired behavior occurs when hitting RRF (at A): all variables of B including the expection that caused the crashed are being serialized
Example for more clarity:
In this case, variable
foo2
plus the exception is serialized when the RRF at A is executed. This makes no sense because flow B is already "gone" by then. Surprisingly, even if the caught exception is nulled (E in the example), it tries to serialize itIt is uncertain why Rhino is doing this