I’m trying to write the backtrace of an error to a file, but all I’m
getting is a SystemExit from glib2. While on the terminal, I have the
usefull backtrace.
I managed to find
, but there is no solution.
From what I understand, GLib captures all exceptions, and reroutes them
to GLib::exit_application. This method outputs things to $stderr before
exiting the ruby program.
I have 2 questions :
why does it work that way ?
Why does the method calls ‘exit’ instead of reraising the exception ?
The method seems to only duplicate the default ruby backtrace, without
anything added.
In [email protected]
“[ruby-gnome2-devel-en] Capture exception in a rescue block” on Thu,
19 Jan 2012 14:27:46 +0100,
Simon A. [email protected] wrote:
From what I understand, GLib captures all exceptions, and reroutes them
to GLib::exit_application. This method outputs things to $stderr before
exiting the ruby program.
I have 2 questions :
why does it work that way ?
We can’t recover from the situation. Showing backtrace is
all what we can do.
GLib.exit_application is only called when an exception is
raised in a callback. It means that an exception is raised
in C world not Ruby world. If it’s raised in Ruby world, we
can recover the situation because Ruby knows how Ruby’s
exception is handled. But if it’s raised in C world, we
don’t have any potal recover way. It’s the reason why we
can’t recover from the situation.
Why does the method calls ‘exit’ instead of reraising the exception ?
We can’t recover from the situation. Showing backtrace is
all what we can do.
GLib.exit_application is only called when an exception is
raised in a callback. It means that an exception is raised
in C world not Ruby world. If it’s raised in Ruby world, we
can recover the situation because Ruby knows how Ruby’s
exception is handled. But if it’s raised in C world, we
don’t have any potal recover way. It’s the reason why we
can’t recover from the situation.
You mean it would be bad to allow people to rescue from such an
exception ? So you ensure you are exiting the ruby script ?
Because, if you replace exit_application code with just raise, it works
to get the backtrace.
Why does the method calls ‘exit’ instead of reraising the exception ?
It’s the same reason menthiond in the above.
You should handle an exception in your callback.
Well, my primary reason to do this is to log exceptions caused by the
users so I can debug them later. But I think I will just redirect stderr
to a file.
In [email protected]
“Re: [ruby-gnome2-devel-en] Capture exception in a rescue block” on
Thu, 19 Jan 2012 15:17:03 +0100,
Simon A. [email protected] wrote:
You mean it would be bad to allow people to rescue from such an
exception ? So you ensure you are exiting the ruby script ?
Because, if you replace exit_application code with just raise, it works
to get the backtrace.
Could you show an example script?
Here are 3 samples.
they override GLib::exit_application to use :
raise
raise exception
(nothing)
The first two shows the backtrace. You can get rid if the rescue close,
and it will show the usual ruby backtrace, or add raise at the end of
the rescue.
The third one does nothing, as expected.
In [email protected]
“Re: [ruby-gnome2-devel-en] Capture exception in a rescue block” on
Thu, 19 Jan 2012 15:17:03 +0100,
Simon A. [email protected] wrote:
You mean it would be bad to allow people to rescue from such an
exception ? So you ensure you are exiting the ruby script ?
Because, if you replace exit_application code with just raise, it works
to get the backtrace.
In [email protected]
“Re: [ruby-gnome2-devel-en] Capture exception in a rescue block” on
Fri, 20 Jan 2012 14:38:27 +0100,
Simon A. [email protected] wrote:
You mean it would be bad to allow people to rescue from such an
exception ? So you ensure you are exiting the ruby script ?
Because, if you replace exit_application code with just raise, it works
to get the backtrace.
Could you show an example script?
Here are 3 samples.
Thanks.
they override GLib::exit_application to use :
raise
raise exception
(nothing)
The first two shows the backtrace. You can get rid if the rescue close,
and it will show the usual ruby backtrace, or add raise at the end of
the rescue.
The third one does nothing, as expected.
Gtk::Button’s clicked signal is a no problem case. Because
the signal doesn’t require return value. (We may be able to
avoid calling #exit_application for those signal handlers.)
There are many signals that requires return value. For
example, “expose-event” requires boolean return value. If we
got an exception, we can’t chose what value should be
returned.
Another example is GLib::Timeout.add, GLib::Idle.add and so
on but they don’t call #exit_application. :< We should fix
them by calling rbgutil_invoke_callback()…
Thanks,
kou
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.