Catching Ruby Exceptions in JavaScript

[Charles Lowell]

Looking at the commonjs specs, I noticed that LoadError is still not caught in The Rhino because it descends from ScriptError which is not a StandardError. This got me to thinking: by default, which exceptions should you be able to catch from JS anyway?

The Racer let's you do any exception (including fatal) which is probably not a good thing.  I'm thinking that -by default- you should be able to catch ScriptError and StandardError, but nothing else. Thus SystemExit, SignalExceptions et al. will penetrate JS exception handlers. 

I'll go ahead and add ScriptError to the list because I think that's a certainty, but exactly what exceptions go into redjs and at what version is unclear to me.

thoughts?

cheers,

Charles

Charles Lowell 

thefrontside.net | twitter: @cowboyd | github: cowboyd

(p) +1.512.207.0229 (f) +1.512.374.0777

[Karol Bucek]

 Oh, I'm sorry should have checked CommonJS out while adding support to expose Ruby exceptions as JS error objects.

I thought StandardError is fine as I did not see any reason to propagate "fatals", I was thinking particularly about LoadError actually but I thought it to be useless.
But now that there's a valid use-case for it we can add those, as stated by adding LoadError, it most probably makes sense to rather add it's superclass ScriptError.
As for others I personally would avoid those but than on the other hand if there's a reasonable demand due a library, than we should think about allowing to configure this via a common context option.

Adding ScriptError to therubyrhino now ...

K.

[Charles Lowell]

On Apr 23, 2012, at 2:11 PM, Karol Bucek wrote:

 Oh, I'm sorry should have checked CommonJS out while adding support to expose Ruby exceptions as JS error objects.

I thought StandardError is fine as I did not see any reason to propagate "fatals", I was thinking particularly about LoadError actually but I thought it to be useless.
But now that there's a valid use-case for it we can add those, as stated by adding LoadError, it most probably makes sense to rather add it's superclass ScriptError.
As for others I personally would avoid those but than on the other hand if there's a reasonable demand due a library, than we should think about allowing to configure this via a common context option.

Adding ScriptError to therubyrhino now ...

Great, I already had added it, but not yet pushed. Shall I add it to redjs suite for > 0.4 ?

cheers,

Charles

[Karol Bucek]

That would be great esp. 0.4 since that is what master is at, thanks Charlie

K.

[Charles Lowell]

On Apr 23, 2012, at 3:42 PM, Karol Bucek wrote:

That would be great esp. 0.4 since that is what master is at, thanks Charlie

Done. See  v0.4.4

I would like to also get exception behavior well defined across libraries, because that is really the only thing keeping us from using commonjs from Less. Specifically:

* what happens in Ruby when a JavaScript exception passes to a Ruby boundary

* what happens when that same exception passes back through to JavaScript?

* what happens in JavaScript when a Ruby exception is raised

* what happens when that same exception passes back to JavaScript.

There are a lot of these elements in place in already, but I think we need to formalize them. Especially what elements are available on the exception object itself, what the backtrace looks like, etc..

As far as less.rb and handlebars.rb, Everything works out of the box minus the pesky `this` argument semantics (I'm really starting to regret that decision), but the exception handling is still not quite right.

The Rhino is raising a NativeException which wraps a org.mozilla.javascript.JavaScriptException and not a Rhino::JSError, so while a Less::ParseError is thrown, it does not contain the correct message and backtrace.

Exception handling is going to be an issue on every wrapped JS lib, so I think it's important to firm up the interface so that it can be depended on.

[Karol Bucek]

 Thanks + the new rhino release looks good as well !

I know of these "limitations" on JRuby + Rhino - exceptions tend to get wrapped and wrapped and is hard to get backtraces right.
Java has it's own stack-traces on top of it JRuby emulates .java + .rb back-traces + Rhino does it's script-stack-tracing.

To get the `Less::Error` behave the same on both runtimes I had to adjust it:
https://github.com/kares/less.rb/commit/e18095585685f7390ef3e9ce5ff6b19a482fe719
But than there's no backtrace specs thus it probably ain't 100% the same ... but hopefully its possible to do.

It would be great to extract the exception/backtrace requirements into RedJS specs, but than what works with V8 might require polishing for Rhino.
I do not expect for backtraces to be 1:1 mappable - but they should be "quiet" similar (contain the same .js parts) - thus maybe before doing a spec release on this the specs should stay open until therubyrhino catches up (which might take a while, hopefully won't).

As for the `this` argument: I know a "repeated" workaround is ugly but usually it's simple fixable (without `defined?(V8)`) :
https://github.com/kares/less-rails/commit/3aad4611d540bbcb968fc5099512973349fecc5b
Of course only as long as the JS function always passes all arguments in ... (e.g. won't work in less.rb).

You solved a valid requirement and I think you're approach is fine, but than I miss the ability to turn it "on" only as needed e.g. on a context level - which would have been perfect for me, since by default it keeps confusing me esp. since with JS functions there's no "argument" errors and arbitrary number of arguments might be passed in no matter the requirements.

Hoja, K.

[Charles Lowell]

On Apr 24, 2012, at 5:36 AM, Karol Bucek wrote:

 Thanks + the new rhino release looks good as well !

I know of these "limitations" on JRuby + Rhino - exceptions tend to get wrapped and wrapped and is hard to get backtraces right.
Java has it's own stack-traces on top of it JRuby emulates .java + .rb back-traces + Rhino does it's script-stack-tracing.

To get the `Less::Error` behave the same on both runtimes I had to adjust it:
https://github.com/kares/less.rb/commit/e18095585685f7390ef3e9ce5ff6b19a482fe719
But than there's no backtrace specs thus it probably ain't 100% the same ... but hopefully its possible to do.

I'll have a look. As long as you can get the error message, I guess the stack shouldn't serve as a blocker.

It would be great to extract the exception/backtrace requirements into RedJS specs, but than what works with V8 might require polishing for Rhino.
I do not expect for backtraces to be 1:1 mappable - but they should be "quiet" similar (contain the same .js parts) - thus maybe before doing a spec release on this the specs should stay open until therubyrhino catches up (which might take a while, hopefully won't).

Agreed. I hope that we're not that far from getting them both 0.7 compatible sooner rather than later.

As for the `this` argument: I know a "repeated" workaround is ugly but usually it's simple fixable (without `defined?(V8)`) :
https://github.com/kares/less-rails/commit/3aad4611d540bbcb968fc5099512973349fecc5b
Of course only as long as the JS function always passes all arguments in ... (e.g. won't work in less.rb).

You solved a valid requirement and I think you're approach is fine, but than I miss the ability to turn it "on" only as needed e.g. on a context level - which would have been perfect for me, since by default it keeps confusing me esp. since with JS functions there's no "argument" errors and arbitrary number of arguments might be passed in no matter the requirements.

I actually want to remove that default behavior in The Racer as soon as possible, once we get proper `this` semantics hammered out. I think we should support it at the context and the instance level.

cheers,

Charles