Exception backtrace for ruby/tk programs

ruby-talk
1

Hello,

I suffered with really hard debugging sessions when an unexpected
exception was thrown from a ruby callback in a ruby/tk application, as
the tk error dialog box showed only the error message itself and no
backtrace. I have had to modify TkCore.callback() to reveal the
backtrace.

Don’t you miss this information? Can this be done in another way? If
not, then here is the simple patch, maybe it can be put into the
mainstream code.

···

root@domesticus:/usr/lib/ruby/1.8# diff -u tk.rb.old tk.rb
— tk.rb.old 2003-10-09 01:18:38.000000000 +0200
+++ tk.rb 2003-10-09 01:40:47.000000000 +0200
@@ -772,7 +772,13 @@

#_get_eval_string(TkUtil.eval_cmd(TkCore::INTERP.tk_cmd_tbl[arg.shift],
# *arg))
cb_obj = TkCore::INTERP.tk_cmd_tbl[arg.shift]

  • cb_obj.call(*arg)
  • begin
  •  cb_obj.call(*arg)
  • rescue
  •  # Append the backtrace to the message, so it can be displayed in

the

  •  # Tk error dialog window.

  •  raise $!, "#{$!} - backtrace: \n#{$!.backtrace.join("\n")}"
  • end
    end

def load_cmd_on_ip(tk_cmd)

Bye:
Ferenc

2

Hello,

I suffered with really hard debugging sessions when an unexpected
exception was thrown from a ruby callback in a ruby/tk application, as
the tk error dialog box showed only the error message itself and no
backtrace. I have had to modify TkCore.callback() to reveal the
backtrace.

Don’t you miss this information?

Can this be done in another way?

how about something simple like this?

~/eg/ruby > cat exception.rb
class Exception
alias __to_s to_s
def to_s; __to_s << “\n” << backtrace.map{|t| “\t#{t}\n”}.join; end
end

def method
raise ‘foo’
end

method

~/eg/ruby > ruby exception.rb
exception.rb:8:in method': foo (RuntimeError) exception.rb:8:in method’
exception.rb:11

    from exception.rb:11

of course perhpas one should use inspect, but you get the idea…

-a

···

On Wed, 8 Oct 2003, Ferenc Engard wrote:

If not, then here is the simple patch, maybe it can be put into the
mainstream code.

root@domesticus:/usr/lib/ruby/1.8# diff -u tk.rb.old tk.rb
— tk.rb.old 2003-10-09 01:18:38.000000000 +0200
+++ tk.rb 2003-10-09 01:40:47.000000000 +0200
@@ -772,7 +772,13 @@

#_get_eval_string(TkUtil.eval_cmd(TkCore::INTERP.tk_cmd_tbl[arg.shift],
# *arg))
cb_obj = TkCore::INTERP.tk_cmd_tbl[arg.shift]

  • cb_obj.call(*arg)
  • begin
  •  cb_obj.call(*arg)
  • rescue
  •  # Append the backtrace to the message, so it can be displayed in

the

  •  # Tk error dialog window.

  •  raise $!, "#{$!} - backtrace: \n#{$!.backtrace.join("\n")}"
  • end
    end

def load_cmd_on_ip(tk_cmd)

Bye:
Ferenc

====================================

Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ara.t.howard@noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
The difference between art and science is that science is what we understand
well enough to explain to a computer. Art is everything else.
– Donald Knuth, “Discover”
~ > /bin/sh -c ‘for lang in ruby perl; do $lang -e “print "\x3a\x2d\x29\x0a"”; done’
====================================

3

Hi,

···

From: Ferenc Engard ferenc@engard.hu
Subject: exception backtrace for ruby/tk programs
Date: Thu, 9 Oct 2003 08:50:56 +0900
Message-ID: 3F84A2C4.15E98C4B@engard.hu

I suffered with really hard debugging sessions when an unexpected
exception was thrown from a ruby callback in a ruby/tk application, as
the tk error dialog box showed only the error message itself and no
backtrace. I have had to modify TkCore.callback() to reveal the
backtrace.

Don’t you miss this information? Can this be done in another way? If
not, then here is the simple patch, maybe it can be put into the
mainstream code.

I think the information is too verbose. So, I truncate the backtrace
based on the difference of the backtrace between pre- and post-calling
callback-body. However, if no exception, it is waste of resources to
get and keep the backtrace. On the CVS, I implement that the particulars
are displayed only if $DEBUG == true.

                              Hidetoshi NAGAI (nagai@ai.kyutech.ac.jp)