Xmlrpc frustration

ruby-talk
1

argh

% cat server.rb
require 'xmlrpc/server'

class ClusterManager
  def start_application args
    p args
    return "ok"
  end
end

server = XMLRPC::Server.new 1998, `hostname`.strip
server.add_handler "ClusterManager", ClusterManager.new
server.serve

% cat test.rb
require 'xmlrpc/client'

client = XMLRPC::Client.new "fatire", nil, 1998

begin
  puts client.call "ClusterManager.start_application", "oogie boogie woogie"
rescue XMLRPC::FaultException => e
  p e
  p e.faultCode
  p e.faultString
end

% ruby test.rb
/usr/local/lib/ruby/1.8/xmlrpc/client.rb:535:in `do_rpc': HTTP-Error:
500 Internal Server Error (RuntimeError)
        from /usr/local/lib/ruby/1.8/xmlrpc/client.rb:409:in `call2'
        from /usr/local/lib/ruby/1.8/xmlrpc/client.rb:399:in `call'
        from test.rb:7

What's up with the 500 Internal Server Error?
(btw, "oogie boogie woogie" printed in the server output).

2

Hi Joe -

Hey, I'm doing some XMLRPC things at the moment too. When I run your
test server and client I get:

···

On Thu, 2005-10-06 at 06:23 +0900, Joe Van Dyk wrote:

argh

% cat server.rb
require 'xmlrpc/server'

class ClusterManager
  def start_application args
    p args
    return "ok"
  end
end

server = XMLRPC::Server.new 1998, `hostname`.strip
server.add_handler "ClusterManager", ClusterManager.new
server.serve

==============
$ ruby client.rb
client.rb:6: warning: parenthesize argument(s) for future version
ok

Yours,

Tom

% cat test.rb
require 'xmlrpc/client'

client = XMLRPC::Client.new "fatire", nil, 1998

begin
  puts client.call "ClusterManager.start_application", "oogie boogie woogie"
rescue XMLRPC::FaultException => e
  p e
  p e.faultCode
  p e.faultString
end

% ruby test.rb
/usr/local/lib/ruby/1.8/xmlrpc/client.rb:535:in `do_rpc': HTTP-Error:
500 Internal Server Error (RuntimeError)
        from /usr/local/lib/ruby/1.8/xmlrpc/client.rb:409:in `call2'
        from /usr/local/lib/ruby/1.8/xmlrpc/client.rb:399:in `call'
        from test.rb:7

What's up with the 500 Internal Server Error?
(btw, "oogie boogie woogie" printed in the server output).

3

There appear to be 2 separate exception mechanisms in Ruby, catch/throw and
rescue/raise/retry. Is this right?

Warren Seltzer

4

I haven't met/read about catch/throw. The begin/rescue/ensure/end is
for sure ;-).

./alex

···

--
.w( the_mindstorm )p.

On 10/19/05, Warren Seltzer <warrens@actcom.net.il> wrote:

There appear to be 2 separate exception mechanisms in Ruby, catch/throw and
rescue/raise/retry. Is this right?

Warren Seltzer

5

Yes, but they're not used for the same thing.

rescue/raise is used to signal error conditions. This is analogous to
Exceptions in Java or C++.

Throw/catch is used to unwind the stack to a desired point. It's like
a labeled break. For example:

catch(:done){
  loop {
    do_work
    if time_to_stop? throw :done
  }
}

It's nice because you can break out of arbitrarily nested loops/blocks/etc.

regards,
Ed

···

On Wed, Oct 19, 2005 at 07:07:05AM +0900, Warren Seltzer wrote:

There appear to be 2 separate exception mechanisms in Ruby, catch/throw and
rescue/raise/retry. Is this right?

6

Not really. A throw just lets one unwind from some deep nesting without
generating a back trace, passing some value along to the catch.

It is much faster and lighter weight than the exception mechanism, and should
be used for cases where a fast, lightweight escape from some deep place is
wanted, perhaps with some passing of data from the deep place to the shallow
place, but where an actual exception isn't needed.

Kirk Haines

···

On Tuesday 18 October 2005 4:07 pm, Warren Seltzer wrote:

There appear to be 2 separate exception mechanisms in Ruby, catch/throw and
rescue/raise/retry. Is this right?

7

Edward Faulkner wrote:

> There appear to be 2 separate exception mechanisms in Ruby,

catch/throw and

> rescue/raise/retry. Is this right?

Yes, but they're not used for the same thing.

rescue/raise is used to signal error conditions. This is analogous to
Exceptions in Java or C++.

Throw/catch is used to unwind the stack to a desired point. It's like
a labeled break. For example:

catch(:done){
  loop {
    do_work
    if time_to_stop? throw :done
  }
}

You probably meant

catch(:done){
  loop {
    do_work
    throw :done if time_to_stop?
  }
}

It's nice because you can break out of arbitrarily nested

loops/blocks/etc.

Plus you can return something from the throw like this:

catch(:done){
  loop {
    do_work
    throw :done, "result" if time_to_stop?
  }
}

Kind regards

    robert

···

On Wed, Oct 19, 2005 at 07:07:05AM +0900, Warren Seltzer wrote: