Configure Rhino not to catch "Java exceptions" in JS try catch block

[Marc Guillemot]

Hi,

when for instance a NullPointerException occurs in method foo of my host
object in a JS code like this one

try
{
...
myHostObject.foo()
...
}
catch (e)
{
// do something
}

the try/catch block will catch it and I won't see that there is a
problem in the Java code of my host object.

It seems to me that it would make sense if users could have the
possibility to configure Rhino to have "Java exceptions" catch in
try/catch block or not. In our case (HtmlUnit) this would allow us to
faster find errors in our host objects.

What do you think?

Cheers,
Marc.
--
Web: http://www.efficient-webtesting.com
Blog: http://mguillem.wordpress.com

[Johan Compagner]

hmm
i think in 1.6RC7 we just have the opposite that those things are not
catched..

But i could be wrong here need to check this

johan

> _______________________________________________
> dev-tech-js-engine-rhino mailing list
> dev-tech-js-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
>

[Marc Guillemot]

Hi Johan,

I don't know how it was in 1.6RC7 (and it fact it doesn't matter for me
anymore).

What's sure is that in head of 1.7R2 (and in head of trunk), MemberBox
uses Context.throwAsScriptRuntimeEx(e) when an InvocationTargetException
occurs. The consequence is that the original expression is wrapped in a
WrappedException which extends EvaluatorException.

Cheers,
Marc.
--
Web: http://www.efficient-webtesting.com
Blog: http://mguillem.wordpress.com

[Attila Szegedi]

This seems fragile to me.

In your place, I'd rather somehow build interception around the host
object. I.e. declare an interface for the host objects, and for
purposes of testing wrap it in a java.lang.reflect.Proxy that reports
exceptions into a log. Or use some AOP solution for achieving
essentialy the same functionality.

Attila.

--
home: http://www.szegedi.org
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com

[Marc Guillemot]

Attila Szegedi wrote:
> This seems fragile to me.

can you detail why?

> In your place, I'd rather somehow build interception around the host
> object. I.e. declare an interface for the host objects, and for purposes
> of testing wrap it in a java.lang.reflect.Proxy that reports exceptions
> into a log. Or use some AOP solution for achieving essentialy the same
> functionality.

I don't want exceptions to be reported into a log: I want them to come up!

An alternative would be to open MemberBox to allow Rhino users to
configure custom MemberBox instances as getter / setter for some slots.
This way I could have my own implementaion of MemberBox.invoke that
doesn't wrap InvocationTargetException's cause in a ScriptRuntimeException.