From: Austin Ziegler <austin@...>
Date: 2002-12-06T21:42:39+09:00
Subject: Re: on error resume next

On Fri, 6 Dec 2002 15:55:31 +0900, Shannon Fang wrote:
> I can't express how I feel :( The code below is just ONE of its
> usage, something else in my mind is:
> 
> begin
>   # do whatever you want to do
> rescue Error A
>   # fix error
>   retry
> rescue Error B
>   resume next
> rescue
>   printe "I can't fix your error"
> end
> 
> In the above, between begin ... rescue Error A, any possible Error
> can occur, if you don't have resume next mechanism, you need to
> wrap the begin end block around the place that the error may
> occur, multi times.

People have managed to implement extremely robust recovery logic
without relying on a VB-style "resume next", though. The problem
with "resume next" is that, ultimately, it's nondeterministic.
(There are cases when Error B is thrown that you may NOT want to
resume next. Because of the nondeterminism behind your sample above,
there's really no way to properly handle that.)

What I'm PERSONALLY suggesting is that you may want to reconsider
how you're designing your program. To me, *needing* a "resume next"
feature suggests that there's something broken with the program's
model and it needs fixing. Exceptions should be handled "locally"
and not propagated upwards; by locally, I mean as close to the
possible source of the exception as possible. Exceptions are only
propagated upwards if they aren't able to be handled at the level
you're dealing with them.

I've also (personally) found that there's no good "generic" error
handling, which is essentially what you're asking for. You can
simulate it in some cases by doing:

  foo rescue op = handle_error
  case op
  when ...
  end

It doesn't do much better than a properly localized
begin/rescue/end block, but it may be preferable for your program's
implementation.

-austin
-- Austin Ziegler, austin@halostatue.ca on 2002.12.06 at 07.28.43