Sorta odd error handling

ruby-talk
1

When an exception gets raised 'all the way out', you get a nice little
call-stack with line-numbers and function names, which really helps
seeing what went wrong, and how. However, I want my application (which
has an infinite mainloop) to keep running, but have that call stack
logged. So I have:

  begin
    run_worker_process queue_entry[:user][:username],
                                    queue_entry[:directory]
  rescue
    log_error $!
  end

This doesn't work particularily well for me, because it only mails out
the actual error, not how it happened. Any ideas on how to improve this?

···

--
Posted via http://www.ruby-forum.com/.

2

Assuming "how it happended" means the stack trace. You can access it
via method backtrace.

Another note: don't use global variables unless you have to. So rather do

begin
...
rescue Exception => e
  # print stackt trace as demo, should be done in log_error
  puts e.backtrace
  log_error e
end

Kind regards

robert

···

2006/6/22, Ohad Lutzky <lutzky@gmail.com>:

When an exception gets raised 'all the way out', you get a nice little
call-stack with line-numbers and function names, which really helps
seeing what went wrong, and how. However, I want my application (which
has an infinite mainloop) to keep running, but have that call stack
logged. So I have:

  begin
    run_worker_process queue_entry[:user][:username],
                                    queue_entry[:directory]
  rescue
    log_error $!
  end

This doesn't work particularily well for me, because it only mails out
the actual error, not how it happened. Any ideas on how to improve this?

--
Have a look: Robert K. | Flickr

3

Hi,

···

In message "Re: Sorta odd error handling" on Thu, 22 Jun 2006 18:53:54 +0900, Ohad Lutzky <lutzky@gmail.com> writes:

logged. So I have:

begin
   run_worker_process queue_entry[:user][:username],
                                   queue_entry[:directory]
rescue
   log_error $!
end

This doesn't work particularily well for me, because it only mails out
the actual error, not how it happened. Any ideas on how to improve this?

Can you show us the actual error? The plain rescue clause captures
exceptions that is subclass of StandardError. The error in question
may not be a subclass.

              matz.

4

errmsg =
     lambda{|e| "%s (%s)\n%s" % [e.message, e.class, (e.backtrace || ).join("\n")]}

   begin
     run_worker_process queue_entry[:user][:username],
                                     queue_entry[:directory]
   rescue Exception => e
     log_error(errmsg[e])
   end

regards.

-a

···

On Thu, 22 Jun 2006, Ohad Lutzky wrote:

When an exception gets raised 'all the way out', you get a nice little
call-stack with line-numbers and function names, which really helps seeing
what went wrong, and how. However, I want my application (which has an
infinite mainloop) to keep running, but have that call stack logged. So I
have:

begin
   run_worker_process queue_entry[:user][:username],
                                   queue_entry[:directory]
rescue
   log_error $!
end

This doesn't work particularily well for me, because it only mails out
the actual error, not how it happened. Any ideas on how to improve this?

--
Posted via http://www.ruby-forum.com/\.

--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama

5

Much thanks! I ended up using a variation on the last guest's
suggestion.

Question: Class Exception has to_s and to_str. Why not include a builtin
function which would return the full textual description that an
interpreter bail-out would print?

···

--
Posted via http://www.ruby-forum.com/.