Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Exception handling
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  5 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Philipp Pirozhkov  
View profile  
 More options Sep 21 2012, 5:50 am
From: Philipp Pirozhkov <pirjs...@gmail.com>
Date: Fri, 21 Sep 2012 02:50:31 -0700 (PDT)
Local: Fri, Sep 21 2012 5:50 am
Subject: Exception handling

Hi all,

I would like to describe my concerns on current exception handling below.
How it is handled currently:

def a
  some_method_that_doesnt_exist
end

begin
  cxt['a'] = method :a
  cxt.eval('a')
rescue V8::JSError => e
  if e.in_ruby?
    puts "some ruby error'
  else
    puts "some JS error'
  end
end

Doesn't look so good, right?

First proposal is to split V8::JSError into V8::JSError::Ruby and
V8::JSError:JS, thus we can rescue them individually or together, using
their common ancestor. (described in
https://github.com/cowboyd/therubyracer/issues/200)

My second concern is that there's no sane way to understand what kind of
exception we got from ruby:

    require 'v8'

    class Ex < StandardError
    end

    class A
      def c
        puts "raising"
        raise Ex.new "i'm a specific ruby exception"
      end
    end

    c = V8::Context.new
    c['a'] = A.new

    begin
      c.eval('a.c')
    rescue Ex => e
      puts "rescued ex: #{e}"
    rescue V8::JSError => e2
      puts "rescued js: #{e2.inspect}"
      puts e2.in_ruby?
    rescue StandardError => e3
      puts "rescued se: #{e3}"
    end

Guess, which one is rescued?
V8::JSError, and `in_ruby?` is returning true.

If we are passing a wrapper for Net::HTTP to JS code, how do we distinguish
between Net::HTTPBadResponse and NoMethodError?
In first case there's an error with networking, and it is recoverable in JS
code (try another host, report, log et c.).
The second case is quite different and means there's an error in evaluated
JS.
How do we distinguish these two?

Let's move to my third concern.
JS is known to be a safe sandbox. If JS is trying to do something
malicious, we should be notified.

require 'v8'

class MaliciousScript < Exception
end

class A
  def a path
    raise MaliciousScript.new "hey, the script is trying to `rm -rf /`!" if path =~ /\//
  end
end

c = V8::Context.new
c['a'] = A.new

begin
  c.eval 'a.a("my")'
  puts "ok"
  c.eval <<-EOF
try {
  a.a("/")

} catch(e){

  // Hey let's hack those bastards!
}

EOF
  puts "No exception!"
rescue MaliciousScript => e
  puts "rescued maliciuos script: #{e}"
rescue V8::JSError => e2
  puts "rescued js: #{e2.inspect}"
  puts e2.in_ruby?
rescue Exception => e3
  puts "rescued se: #{e3}"
end

Guess what?

ok
No exception!

My proposals here abridged:

1. Split V8::JSError into two, JS specific and Ruby specific
2. Let Ruby catch ruby specific exceptions in a straightforward way
3. Restrict JS from catching exceptions it's not intended to catch

Please let me know what you think.

PS Just for the case you may have questions regarding what i'm doing. I'm
working on a platform which allows users to host and execute JS, and it's
Ruby controlled/based. I provide an API to JS, and would like to do so in a
controlled way.

PPS Should I crosspost/move this to javascript-and-friends? Not sure if
it's common to therubyrhino or execjs.

BR, Phil


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Philipp Pirozhkov  
View profile  
 More options Sep 21 2012, 8:53 am
From: Philipp Pirozhkov <pirjs...@gmail.com>
Date: Fri, 21 Sep 2012 05:53:54 -0700 (PDT)
Local: Fri, Sep 21 2012 8:53 am
Subject: Re: Exception handling

0.11.0beta8 has a bit different V8::Error, and it allows calling .cause to
get the original exception
So the code can be

begin
  begin
    cxt.eval script
  rescue V8::Error => e
    raise e.cause if e.in_ruby?
    # JS specific error handling
   end
rescue SomeCustomError => e
  ...
end


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Charles Lowell  
View profile  
 More options Sep 27 2012, 9:46 am
From: Charles Lowell <cowb...@thefrontside.net>
Date: Thu, 27 Sep 2012 16:46:14 +0300
Local: Thurs, Sep 27 2012 9:46 am
Subject: Re: [therubyracer] Exception handling

On Sep 21, 2012, at 12:50 PM, Philipp Pirozhkov wrote:

Does the new error handling in 0.11.0 address these concerns?

This is definitely NOT good. Thanks for spotting this.

> My proposals here abridged:

> 1. Split V8::JSError into two, JS specific and Ruby specific
> 2. Let Ruby catch ruby specific exceptions in a straightforward way

we could mix in modules to the V8::Error instance indicating whether the root cause was in ruby or Javascript

module V8::Error:JS
end
module V8::Error::Ruby
end

that way, you could distinguish (optionally) in your rescue

begin
rescue V8::Error::JavaScriptError => e
  #root cause from JS
rescue V8::Error::RubyError => e
  #root cause was from Ruby
rescue V8::Error
 #don't care which language originated the exception, only that one did occur during JS evaluation
end

> 3. Restrict JS from catching exceptions it's not intended to catch

This is tichy, need to dig into V8 to see how to do this, but it is critical for sandboxing. This is easier in Rhino, I think.

> Please let me know what you think.

> PS Just for the case you may have questions regarding what i'm doing. I'm working on a platform which allows users to host and execute JS, and it's Ruby controlled/based. I provide an API to JS, and would like to do so in a controlled way.

I'd love to hear your thoughts on this. If you want to take a stab at time boxing scripts in V8 (like you can already do with Rhino) I'd be happy to help you with it.

> PPS Should I crosspost/move this to javascript-and-friends? Not sure if it's common to therubyrhino or execjs.

Since therubyracer and therubyrhino share a common api, I think it is wise. I'll do so.

> BR, Phil

Charles Lowell
thefrontside.net | twitter: @cowboyd | github: cowboyd
(p) +1.512.207.0229 (f) +1.512.374.0777

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Philipp Pirozhkov  
View profile  
 More options Oct 3 2012, 5:29 pm
From: Philipp Pirozhkov <pirjs...@gmail.com>
Date: Wed, 3 Oct 2012 14:29:10 -0700 (PDT)
Local: Wed, Oct 3 2012 5:29 pm
Subject: Re: [therubyracer] Exception handling

> Does the new error handling in 0.11.0 address these concerns?

It's really really better now. I've finally moved to 0.11 today and that
was the only way to handle one kind of errors. I believe this could be done
by major refactorings, but with 0.11 it was quick and simple to get the
root error as `cause` and set an `if`.

we could mix in modules to the V8::Error instance indicating whether the

> root cause was in ruby or Javascript

Both subclassing and mixins should work and will look just the same from
caller/rescuer's perspective.

> that way, you could distinguish (optionally) in your rescue

> begin
> rescue V8::Error::JavaScriptError => e
>   #root cause from JS
> rescue V8::Error::RubyError => e
>   #root cause was from Ruby
> rescue V8::Error
>  #don't care which language originated the exception, only that one did
> occur during JS evaluation
> end

Yep, looks perfect.

I'd love to hear your thoughts on this. If you want to take a stab at time

> boxing scripts in V8 (like you can already do with Rhino) I'd be happy to
> help you with it.

Really appreciated. Will time boxing allow for limiting the execution of
the script somehow? I wonder if this is V8 already. Is that something like
Firefox's feature "the script processing is taking to long, do you want to
stop it?" ?

BR, Phil


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Charles Lowell  
View profile  
 More options Oct 3 2012, 6:15 pm
From: Charles Lowell <cowb...@thefrontside.net>
Date: Wed, 3 Oct 2012 17:15:08 -0500
Local: Wed, Oct 3 2012 6:15 pm
Subject: Re: [therubyracer] Exception handling

On Oct 3, 2012, at 4:29 PM, Philipp Pirozhkov wrote:

Karol, is this agreeable then if we use a scheme like this with subclasses and/or modules?

class V8::JavaScriptError < V8::Error # in_ruby? == false; in_javascript? == true

class V8::RubyError < V8::Error # in_ruby? == true; in_javascript? == false

I'm open to other names for the exceptions.

> I'd love to hear your thoughts on this. If you want to take a stab at time boxing scripts in V8 (like you can already do with Rhino) I'd be happy to help you with it.
> Really appreciated. Will time boxing allow for limiting the execution of the script somehow? I wonder if this is V8 already. Is that something like Firefox's feature "the script processing is taking to long, do you want to stop it?" ?

This facility does exist in V8 and it is exposed in 0.11, but only at the very low-level metal. We'd need to implement the Rhino interface for V8 based on this low level. Unfortunately, V8 does not give you instruction level callbacks from the JavaScript VM. Instead you have to have a monitoring thread that pre-empts the javascript execution thread and terminates it forcibly if it exceeds the allotted time box. Would love to get together and work on this. When are you available generally?

cheers,
Charles

> BR, Phil

Charles Lowell
thefrontside.net | twitter: @cowboyd | github: cowboyd
(p) +1.512.207.0229 (f) +1.512.374.0777

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions Older topic »