Tools
Sign in
Login
Forum
Exception wrapping in ThrowJavaException and RethrowJavaException
Forum
>
Scripting
>
Exception wrapping in ThrowJavaException and RethrowJavaException
n/A
posted
on July 9, 2013
at 9:36 AM
n/A
posted
on July 9, 2013
at 9:36 AM
The documentation of ThrowJavaException and RethrowJavaException state:
Please note that if this Exception is not a RuntimeException, it will be wrapped with an NmRuntimeException.
This does not preclude the functions from wrapping all other exceptions too, but the text suggests that runtime exceptions are not wrapped.
However, in Appway 5.2.3.5, the following code,
1
Try
2
ThrowJavaException('java.lang.RuntimeException');
3
Catch
4
PRINTLN($exception);
5
End
Shows that the exception is wrapped:
com.nm.sdk.NmEvaluatorException: [token:ThrowJavaException, line:2, charpos:3, scope:Try:try, functionStack:null]
What are the rules for wrapping?
n/A
replied
on July 15, 2013
at 10:49 AM
n/A
replied
on July 15, 2013
at 10:49 AM
The Try-Catch block implementation wraps the exceptions it captures in a NmEvaluatorException. The documentation of the function ThrowJavaException is correct, in fact if you try the following:
1
Try
2
ThrowJavaException('java.util.zip.DataFormatException');
3
Catch
4
PRINTLN($exception);
5
End
The printout will be:
1
com.nm.sdk.NmEvaluatorException: java.util.zip.DataFormatException [token:ThrowJavaException, line:2, charpos:3, scope:Try:try, functionStack:null]
The reason is the java.util.zip.DataFormatException is not a RuntimeException, so the ThrowJavaException function wraps it in a new NmRuntimeException. The thing is, in both cases, yours and mine, the Try-Catch block implementation will then check if the exception is an instance of NmEvaluatorException and if so it will throw it as is, otherwise it will create a new NmEvaluatorException copying over only the message and the stacktrace of the original exception.
Why would you need to use a specific Java Exception in the first place?
Emilie Boillat
replied
on July 22, 2013
at 11:48 AM
Emilie Boillat
replied
on July 22, 2013
at 11:48 AM
Hi Biƶrn, which document are you referring to? I can't seem to find it...
n/A
replied
on August 28, 2013
at 11:01 AM
n/A
replied
on August 28, 2013
at 11:01 AM
Emilie, I am referring to the inline documentation of the two functions (Javadoc equivalent), the one that is shown when you, e.g, double-click on the function name in a script editor. Do you have an official name for that documentation?
Mauro, I understand your example, it complies with the documentation; DataFormatException is not a RuntimeException. However, I am interested in the behavior when a RuntimeException is encountered. The documentation does not state whether such an exception will be wrapped or not. If you execute ThrowJavaException(java.lang.RuntimeException) in the interactive script editor, you see that it is wrapped.
Why am I interested in using a specific Java Exception? If one is serious about exception handling, then one needs to check the exceptions that are caught. You don't want to treat all possible exceptions the same way. One example I encountered last week: our solution invokes an integration link from withing a Try-Catch block. The code was refactored slightly, and after that the solution reported that there was an error when invoking integration link. However, the problem was a null pointer exception inside the Try-Catch block, due to the refactoring. If we had been checking the type of exception that we are catching, we would not have handled the null pointer exception and it could have been logged by Appway. One might, of course, argue that our code could have been rearranged such that the dereferencing takes place outside the Try-Catch block. But then, what about a function that can throw two types of exceptions and you want to handle only one of them? For example, a null pointer exception inside the function?
Now, in order to check what type of exception one has caught in the Catch block one needs to know whether the expected exception has been wrapped or not -- whether to call $exception.getCause() or to use $exception straight away.
n/A
replied
on August 28, 2013
at 11:14 AM
n/A
replied
on August 28, 2013
at 11:14 AM
Another thing I just noticed: the documentation states that the exception is wrapped in an NmRuntimeException. That is true. But the NmRuntimeException is again wrapped in an NmEvaluatorException.
ThrowJavaException(java.lang.Throwable, 'Test')
yields:
com.nm.sdk.NmEvaluatorException: java.lang.Throwable: Test [token:ThrowJavaException, line:1, charpos:0, scope:null, functionStack:null]
at com.nm.sdk.data.expeval.nodes.FunctionNode.execute(FunctionNode.java:465)
...
at java.lang.Thread.run(Thread.java:662)
Caused by: com.nm.sdk.NmRuntimeException: java.lang.Throwable: Test
at com.nm.exprlang.functions.ThrowJavaExceptionFunction.calculate(ThrowJavaExceptionFunction.java:67)
at com.nm.sdk.data.expeval.MethodCallUtils.callScriptFunction(MethodCallUtils.java:97)
at com.nm.sdk.data.expeval.nodes.FunctionNode.execute(FunctionNode.java:459)
... 78 more
Caused by: java.lang.Throwable: Test
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.nm.exprlang.functions.ThrowJavaExceptionFunction.calculate(ThrowJavaExceptionFunction.java:58)
... 80 more
Please
sign in
to add a reply
About this site
|
Terms of use
|
Privacy statement
|
Contact us
© 2025 Appway AG. All Rights Reserved.
This does not preclude the functions from wrapping all other exceptions too, but the text suggests that runtime exceptions are not wrapped.
However, in Appway 5.2.3.5, the following code,
Shows that the exception is wrapped:
What are the rules for wrapping?