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 Johan Compagner wrote: > 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 > > On Wed, Dec 10, 2008 at 11:38, Marc Guillemot <[EMAIL PROTECTED]> wrote: > >> 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 >> _______________________________________________ >> dev-tech-js-engine-rhino mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino >> _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
