Exception that doesn't stop program flow

Okay… this might sound weird (contradictory even) but is there a way
in Ruby to create an exception that can be caught at any level above the
point of origin, but /doesn’t/ actually interrupt program flow when it
is raised? In a program I am writing, a certain sort of event occurs
that I have to be sure to deal with later on outside of the function,
but I don’t want it to interrupt the function because it will leave
object data inconsistent. I probably just need to write another event
class and pop this onto some kind of global queue; but I thought I might
as well ask in case there is something helpful I have overlooked.

Terry M. [email protected] writes:

Okay… this might sound weird (contradictory even) but is there a way
in Ruby to create an exception that can be caught at any level above the
point of origin, but /doesn’t/ actually interrupt program flow when it
is raised? In a program I am writing, a certain sort of event occurs
that I have to be sure to deal with later on outside of the function,
but I don’t want it to interrupt the function because it will leave
object data inconsistent. I probably just need to write another event
class and pop this onto some kind of global queue; but I thought I might
as well ask in case there is something helpful I have overlooked.

Sounds to me like the observer pattern:

http://www.ruby-doc.org/stdlib/libdoc/observer/rdoc/index.html

sherm–

On Sat, Feb 12, 2011 at 8:15 AM, Terry M.
[email protected] wrote:

Okay… this might sound weird (contradictory even) but is there a way
in Ruby to create an exception that can be caught at any level above the
point of origin, but /doesn’t/ actually interrupt program flow when it
is raised? In a program I am writing, a certain sort of event occurs
that I have to be sure to deal with later on outside of the function,
but I don’t want it to interrupt the function because it will leave
object data inconsistent. I probably just need to write another event
class and pop this onto some kind of global queue; but I thought I might
as well ask in case there is something helpful I have overlooked.

If you have to restore the object’s integrity after an exceptional
event, you can use an ensure block. An ensure block is always called,
after the correct execution or in light of an exception, before
returning:

def method
puts “in the block”
begin
puts “in the block that raises”
raise “Exception ocurred”
ensure
puts “restoring object integrity”
end
end

begin
method
rescue
puts “rescuing the exception”
end

Here you handle everything you need to do to safely return from the
method in the ensure block, and the exception will be still raised.

Jesus.

On Sat, Feb 12, 2011 at 2:15 AM, Terry M.
[email protected] wrote:

Okay… this might sound weird (contradictory even) but is there a way
in Ruby to create an exception that can be caught at any level above the
point of origin, but /doesn’t/ actually interrupt program flow when it
is raised?

There are a few ways to do this. One way to return side-band data like
this is to set a thread-local variable and check its value later on. A
clean-ish way to do this is to make a method that encapsulates the
error check:

def handle_errors
yield
if Thread.current[:error]
# handle error
Thread.current[:error] = nil
end
end

handle_errors do

… code that might set the error flag …

end

Terry M. wrote in post #981237:

Okay… this might sound weird (contradictory even) but is there a
way in Ruby to create an exception that can be caught at any level
above the point of origin, but /doesn’t/ actually interrupt program
flow when it is raised?

When a printer is halfway through a 200-page job and it runs out of
paper, it pauses. When someone feeds it more paper, it continues from
where it left off.

Imagine a printer which, when it ran out of paper, shredded everything
it just printed! “Out of paper,” it beeps, as chopped bits of the
previously-perfectly-fine first 100 pages are ejected into the air.

Exceptions behave like the latter case. You lose the running state of
the program–the (possibly deep) stack is lost.

We often want program errors to be handled the way a regular printer
handles them, not the way the above printer/shredder combo does. When
an error occurs, execution should pause while a control panel pops up
awaiting instruction. If the error occurs inside a library, for
example, the library authors are responsible for the control panel.

This kind of multi-stage error-handling was perfected long ago in the
Lisp condition system. The buttons on the control panel are called
restarts and the thing that pushes a button is called a handler.

I ported the condition system to Ruby after I lost the results of an
hours-long running program due to a trivial glitch in the input
data. This Rubified condition system has served me well, though I’m
sure nobody else uses it: http://cond.rubyforge.org

On Mon, Feb 14, 2011 at 9:43 AM, Avdi G. [email protected]
wrote:

I’m intrigued. I’m in the process of writing an eBook on handling
failures in Ruby (http://avdi.org/devblog/exceptional-ruby/), and just
this morning I finished a section on alternatives to exceptions. I’m
going to have to play with this… it may warrant some coverage in the
book. I’ve thought for a long time that Ruby could use to borrow some
of Lisp’s condition system.

+1

On Sun, Feb 13, 2011 at 1:54 PM, James M. Lawrence
[email protected] wrote:

I ported the condition system to Ruby after I lost the results of an
hours-long running program due to a trivial glitch in the input
data. This Rubified condition system has served me well, though I’m
sure nobody else uses it: http://cond.rubyforge.org

I’m intrigued. I’m in the process of writing an eBook on handling
failures in Ruby (http://avdi.org/devblog/exceptional-ruby/), and just
this morning I finished a section on alternatives to exceptions. I’m
going to have to play with this… it may warrant some coverage in the
book. I’ve thought for a long time that Ruby could use to borrow some
of Lisp’s condition system.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs