Customizing Exception, but only when an error is raised

Hi all,

Say I do something like this do the Exception class:

class Exception
    alias :old_init :initialize
    def initialize(*args)
       old_init(*args)
       do_stuff
    end

    def do_stuff
       puts "Hello World!"
    end
end

And, I want +do_stuff+ to fire off if an error is *raised* but not if it is caught (and not re-raised). In other words, I would expect +do_stuff+ to fire off in this example:

begin
    0/0
rescue ZeroDivisionError
    raise
end

But I don't want to fire off in this example:

begin
    0/0
rescue ZeroDivisionError
    # Do nothing
end

Is there a way I can accomplish this?

Thanks,

Dan

Hi all,

Say I do something like this do the Exception class:

class Exception
   alias :old_init :initialize
   def initialize(*args)
      old_init(*args)
      do_stuff
   end

   def do_stuff
      puts "Hello World!"
   end
end

And, I want +do_stuff+ to fire off if an error is *raised* but not if
it is caught (and not re-raised). In other words, I would expect
+do_stuff+ to fire off in this example:

begin
   0/0
rescue ZeroDivisionError
   raise
end

But I don't want to fire off in this example:

begin
   0/0
rescue ZeroDivisionError
   # Do nothing
end

The moment an exception is thrown an exception istance is created. So your code will be invoked on every raise. No way to prevent that if you put it into the constructor.

Is there a way I can accomplish this?

Write a custom method that does the raising.

def my_raise(cl,*a)
  ex = cl.new(*a)
  ex.do_stuff
  raise ex
end

Kind regards

    robert

···

Daniel Berger <Daniel.Berger@qwest.com> wrote:

Robert Klemme wrote:

Hi all,

Say I do something like this do the Exception class:

class Exception
   alias :old_init :initialize
   def initialize(*args)
      old_init(*args)
      do_stuff
   end

   def do_stuff
      puts "Hello World!"
   end
end

And, I want +do_stuff+ to fire off if an error is *raised* but not if
it is caught (and not re-raised). In other words, I would expect
+do_stuff+ to fire off in this example:

begin
   0/0
rescue ZeroDivisionError
   raise
end

But I don't want to fire off in this example:

begin
   0/0
rescue ZeroDivisionError
   # Do nothing
end

The moment an exception is thrown an exception istance is created. So your code will be invoked on every raise. No way to prevent that if you put it into the constructor.

Just 'raise' by itself seems to raise the same exception object (it
does not even #dup it I think) so the #initialize would only work
whenever an Exception is raised the first time.

Is there a way I can accomplish this?

Write a custom method that does the raising.

def my_raise(cl,*a)
ex = cl.new(*a)
ex.do_stuff
raise ex
end

Kind regards

   robert

E

···

Daniel Berger <Daniel.Berger@qwest.com> wrote:

ES wrote:

Robert Klemme wrote:

Hi all,

Say I do something like this do the Exception class:

class Exception
   alias :old_init :initialize
   def initialize(*args)
      old_init(*args)
      do_stuff
   end

   def do_stuff
      puts "Hello World!"
   end
end

And, I want +do_stuff+ to fire off if an error is *raised* but not
if it is caught (and not re-raised). In other words, I would expect
+do_stuff+ to fire off in this example:

begin
   0/0
rescue ZeroDivisionError
   raise
end

But I don't want to fire off in this example:

begin
   0/0
rescue ZeroDivisionError
   # Do nothing
end

The moment an exception is thrown an exception istance is created.
So your code will be invoked on every raise. No way to prevent that
if you put it into the constructor.

Just 'raise' by itself seems to raise the same exception object (it
does not even #dup it I think) so the #initialize would only work
whenever an Exception is raised the first time.

Right! Still that does not help to achive the behavior Daniel wanted
because he wanted to prevent action for some initial raised exceptions.
:slight_smile:

Is there a way I can accomplish this?

Write a custom method that does the raising.

def my_raise(cl,*a)
ex = cl.new(*a)
ex.do_stuff
raise ex
end

Strictly speaking this suggestion of mine would not solve the problem
either, as this would require to change internal code (the one that
detects division by zero).

But then again, there is no real solution to this problem for very
fundamental reasons (especially causality): at the moment an exception is
thrown it cannot know how it will be handled. You *must* do the
distinction in the catch clause - if you feel you need to do it.

It would be interesting to learn what real world problem Daniel wants to
solve...

Kind regards

    robert

···

Daniel Berger <Daniel.Berger@qwest.com> wrote: