Raise and rescue

Ruby
1

Is is possible to raise an exception then rescue it and then go back to
whereever it was raised and continue with execution?
For example,
class Test
end

begin
code line 1
code line 2
code line 3
code line 4
code line 5
raise Class.new
code line 7
code line 8
code line 9

rescue Class
#here in some cases send back execution to code line 7

ensure
end

Thanks.

2

On Fri, Jun 13, 2008 at 2:58 PM, Misiek Sz [email protected] wrote:

Is is possible to raise an exception then rescue it and then go back to
wherever it was raised and continue with execution?

No.

Daniel Brumbaugh K.

3

You might be able to achieve something like that with an in-line
rescue
though. Like…

code line 1
code line 2
code line 3
code line 4
code line 5
raise Class.new rescue some_method_to_cope
code line 7
code line 8
code line 9

James

On Fri, Jun 13, 2008 at 4:48 PM, Daniel Brumbaugh K. <

4

On 13.06.2008 21:58, Misiek Sz wrote:

code line 4
end
There is no way - and for good reason. An exception is thrown because
execution cannot proceed at that line.

There is however retry, but it will continue from the beginning of the
block:

irb(main):001:0> i = 0
=> 0
irb(main):002:0> begin
irb(main):003:1* puts 1
irb(main):004:1> raise “Foo”
irb(main):005:1> rescue Exception
irb(main):006:1> puts 2
irb(main):007:1> i += 1
irb(main):008:1> retry if i < 3
irb(main):009:1> end
1
2
1
2
1
2
=> nil
irb(main):010:0>

Kind regards

robert

5

Robert K. wrote:

code line 3
ensure
end

There is no way - and for good reason. An exception is thrown because
execution cannot proceed at that line.

So how would you do something that requires user intervention, say in
putting more paper in a printer? A lot of my programs require files or
other resources that may not always be available and I have programmed
them so that an error message is displayed and the operator can fix the
problem and continue or abort the program. A very good example is when
a user tries to bring up an account that is in use by another user. The
program states that the record is busy and the operator can wait for the
record to be freed and continue or go to another account.
I can see how to do this in Ruby by using something like a while loop
but that requires that the code surround every possible trouble spot
rather than having a “generic” exception handling routine like I
currently use in Business Basic.

6

On Fri, Jun 13, 2008 at 5:34 PM, Michael W. Ryder
[email protected] wrote:

So how would you do something that requires user intervention, say in
putting more paper in a printer?

def foo
do_something
ensure_printer
do_more
end
def ensure_printer
return true if printer_available?
if confirm ‘you’re printer has no paper. Try again?’
ensure_printer
else
raise NoPaperError
end
end

That’s how I would imagine your problem to look. If there isn’t paper,
then it asks the user whether to try again, otherwise, it throws a
NoPaperError which gets handled somewhere.

Daniel Brumbaugh K.

7

On Fri, Jun 13, 2008 at 5:34 PM, Michael W. Ryder
[email protected] wrote:

So how would you do something that requires user intervention, say in
putting more paper in a printer?

def foo
do_something

Daniel Brumbaugh K.

8

Daniel Brumbaugh K. wrote:

On Fri, Jun 13, 2008 at 5:34 PM, Michael W. Ryder
[email protected] wrote:

So how would you do something that requires user intervention, say in
putting more paper in a printer?

def foo
do_something

Maybe I am missing the point here but it doesn’t appear that it would do
what I have been doing for over 20 years with Business Basic. There I
enter a line saying SETERR 9200 at the beginning of the program and the
program automatically goes to that line when an error occurs anywhere in
the program. From there I can display a message saying what is wrong
and the operator can fix the problem and continue with the program or
abort the program.
Your example seems to require that I call a method anytime I run into a
problem. This would seem to require that each possible problem area be
surrounded by a while loop much like I have done in C.

9

On 14.06.2008 00:31, Michael W. Ryder wrote:

Robert K. wrote:

There is no way - and for good reason. An exception is thrown because
execution cannot proceed at that line.

So how would you do something that requires user intervention, say in
putting more paper in a printer? A lot of my programs require files or
other resources that may not always be available and I have programmed
them so that an error message is displayed and the operator can fix the
problem and continue or abort the program.

That’s exactly the case where /retry/ is meant for. Catch the
exception, do something and then retry the block of code (see the
example I posted earlier).

A very good example is when
a user tries to bring up an account that is in use by another user. The
program states that the record is busy and the operator can wait for the
record to be freed and continue or go to another account.
I can see how to do this in Ruby by using something like a while loop
but that requires that the code surround every possible trouble spot
rather than having a “generic” exception handling routine like I
currently use in Business Basic.

See above.

irb(main):007:1> i += 1
irb(main):008:1> retry if i < 3
irb(main):009:1> end
1
2
1
2
1
2
=> nil
irb(main):010:0>

Cheers

robert

10

On Sat, 2008-06-14 at 06:09 +0900, Robert K. wrote:

There is no way - and for good reason. An exception is thrown because
execution cannot proceed at that line.

This is not a “good reason”. Having used languages with restartable
exceptions I can pretty much guarantee you that it is not only possible,
but often desirable to have restartable exceptions. Consider this use
case:

  1. The software commences a procedure that is time-consuming and that
    requires lots of memory.
  2. In the middle of this it runs out of memory. An exception is raised.

In the Ruby (and many other languages) world, I’m boned. I have to
throw away all the time and memory spent to get where I am, free up
memory in some way, and then restart the whole thing. This could be a
non-trivial operation (and, indeed, for this use case, is defined as
such). In a world with restartable exceptions, however, the use case
continues thus:

  1. The exception handler pops up a dialogue/prompt/whatever telling me
    that memory is low. It suggests actions I can take to free up enough
    memory. Let’s say I choose to kill memory hogs like Firefox or
    OpenOffice.org. I click “continue” (or type or whatever the UI is).
  2. The exception handler retries the very line of code that failed. All
    of the expensive, time-consuming setup that led to that point is still
    there and still ready for action.

(Please note at this point that this is only one example. I could
probably, given an hour, come up with a hundred situations in which
restartable exceptions are useful and desirable. Too, the handler’s
actions are only one of a thousand possible reactions it could have.
Maybe for efficiency’s sake I’m memoizing a whole bunch of calculations.
If I run out of memory in this case, the handler could clear the LRU
memo cache entries for twice the amount of reported memory being claimed
as a quick heuristic. This would be totally transparent to the user
except for a slight hiccough in performance.)

Now it is possible in the Ruby model to partition things in many
situations such that a retry only executes a small amount of code
instead of the huge setup alluded to above. This is a problem, however,
for several reasons:

  1. You’re putting in unnecessary scaffolding code solely because of the
    language’s shortcomings. (Shades of C++ and Java here, albeit very,
    very, very minuscule shades.) This clutters code, constrains
    architecture and generally is, to my eyes, anti-Ruby.
  2. Not all problems can be built this way. For those problems which
    cannot be set up this way, you’re boned.
  3. Most importantly, you’re constraining your very thinking about
    problems. There will be approaches to problems you simply will not
    think of because the very language conspires against your thinking down
    those lines.
11

On Jun 13, 6:25 pm, “Michael W. Ryder” [email protected]
wrote:

Maybe I am missing the point here but it doesn’t appear that it would do
what I have been doing for over 20 years with Business Basic. There I
enter a line saying SETERR 9200 at the beginning of the program and the
program automatically goes to that line when an error occurs anywhere in
the program. From there I can display a message saying what is wrong
and the operator can fix the problem and continue with the program or
abort the program.

That’s true, and one of the trade-offs inherent to switching error
handling from a GOTO control structure to a scoped control structure
(such as bounded exception handling). The disadvantage is, as you’ve
explained, that each problem area must be contained within its own
error handling scope. The overwhelming advantage is that by catching
errors as close to their occurrence as possible, it becomes much
easier to identify just what went wrong, or pass the responsibility up
to the next thing that can. Exceptions were invented to help
programmers manage the complexity of handling errors.

Your example seems to require that I call a method anytime I run into a
problem. This would seem to require that each possible problem area be
surrounded by a while loop much like I have done in C.

It is possible to catch all (most) exceptions by placing your entire
program in a begin-rescue block, and the rescue procedure would
approximate what happens in the BASIC interrupt method. But if you do
that, the disadvantage to the BASIC approach might become clear as you
try to recover from the error. You’ll have to know where to continue
execution, as well as make sure that the rest of the application is in
a similar state as it was before the error interrupted it.

For a good description of the topic, check this out:

I hope this helps, and good luck with your project!

12

There is no direct way, but you can implement it using continuations
(would not be supported in 1.9 though …)

See attached file

Sylvain

13

On Sat, Jun 14, 2008 at 6:43 AM, Michael T. Richter
[email protected] wrote:

  1. The exception handler pops up a dialogue/prompt/whatever telling me that
    memory is low. It suggests actions I can take to free up enough memory.
    Let’s say I choose to kill memory hogs like Firefox or OpenOffice.org. I
    click “continue” (or type or whatever the UI is).
  2. The exception handler retries the very line of code that failed. All of
    the expensive, time-consuming setup that led to that point is still there
    and still ready for action.

If you really must do this and you’re using 1.8, just throw the
current continuation up the stack, and then resume it when when the
memory issue is theoretically resolved… I’m not going to go into
detail, though, because a) I don’t have time; and b) I’m going to be
very opinionated here and say you really ought to be looking into
better architecting your system to deal with memory crunches without
these contortions, if you actually expect to be running out of memory
a lot. However, look up calcc, and have fun.

–
Avdi

Home: http://avdi.org
Developer Blog: Avdi Grimm, Code Cleric
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com