Disabling exceptions - thoughts?

Hi all,

On #ruby-lang tonight, the topic of disabling exceptions came up. In Perl,
for example, you can temporarily (or permanately) disable particular (or all)
warnings via a “no warnings” pragma. I’m told CommonLisp also has something
along these lines.

Ignoring the “is it wise” for the moment, is it possible to disable
exceptions in Ruby? i.e. something along the lines of:

Errno::EEXIST.ignore # ignore exception globally
Errno::EEXIST.ignore{…} # ignore exception for block only

I know there are questions:

“What about classes/modules that expect those exceptions to be defined?”

“Could we use file scope via FILE”?

“Wouldn’t a no-op work just as well?”

“Is this even possible in the current version of Ruby?”

I don’t know the answer to any of the above questions, and I’m sure there are
even more questions than I’m listing.

But, that’s why I’m asking you all. :slight_smile:

Regards,

Dan

PS - Some parts of this message inspired/stolen from seanc, matju and
zenspider

Hi,

···

In message “Disabling exceptions - thoughts?” on 02/09/13, Daniel Berger djberge@attbi.com writes:

On #ruby-lang tonight, the topic of disabling exceptions came up. In Perl,
for example, you can temporarily (or permanately) disable particular (or all)
warnings via a “no warnings” pragma. I’m told CommonLisp also has something
along these lines.

Ignoring the “is it wise” for the moment, is it possible to disable
exceptions in Ruby?

Not in the current implementation. Besides we should define first
what is going to happen on exceptional situation when exception is
turned off.

						matz.

>On #ruby-lang tonight, the topic of disabling exceptions came up. In Perl,
>for example, you can temporarily (or permanately) disable particular (or all)
>warnings via a "no warnings" pragma. I'm told CommonLisp also has something
>along these lines.
>
>Ignoring the "is it wise" for the moment, is it *possible* to disable
>exceptions in Ruby?

Not in the current implementation. Besides we should define first
what is going to happen on exceptional situation when exception is
turned off.

You mean if the exception isn't being ignored? It should be raised as
a normal exception would and left to the current stack. You mean
something like a different exception or a possible bug? Here's some
broken pseudo code that doesn't actually work, but illustrates the
idea:

Errno::EEXISTS.ignore do
  Dir.mkdir('/usr')
  Dir.mkdir('/usr/ports')
  Dir.mkdir('/usr/ports/databases')
  Dir.mkdir('/usr/ports/databases/postgresql-devel')
end

I know there are work arounds, but writing:

begin
  Dir.mkdir('/usr')
rescue Errno::EEXISTS
end

begin
  Dir.mkdir('/usr/ports')
rescue Errno::EEXISTS
end
etc...

gets tedious. I know that in CL you can turn specific exceptions off
(thx matju) and that there are other ways to code this, but in short
hack scripts that system admins use/write, it's pretty nice to be able
to just disregard a specific exception.

Here's some more broken code to try and illustrate the idea:

class Exception
  def Exception.ignore(reraise_count = nil, &proc)
    exception_count = reraise_count.to_i
    begin
      yield(proc)
    rescue self.class
      exception_count -= 1 if exception_count.kind_of? Fixnum
      if reraise_count.nil? or reraise_count != 0
        # This implies that a proc object knows what instruction the
        # proc object left off on
        proc.resume()
      end
    end # begin
  end # def Exception.ignore()
end # class Exception

Just an idea. -sc

···

--
Sean Chittenden

Sat, 14 Sep 2002 03:30:51 +0900, Sean Chittenden sean@ruby-lang.org pisze:

I know there are work arounds, but writing:

begin
Dir.mkdir(’/usr’)
rescue Errno::EEXISTS
end

begin
Dir.mkdir(’/usr/ports’)
rescue Errno::EEXISTS
end
etc…

gets tedious.

Don’t repeat, wrap in a function. Or make a loop.

def ensureDirExists(name)
Dir.mkdir(name)
rescue Errno::EEXISTS
end

for dir in [’/usr’, ‘/usr/ports’, ‘/usr/ports/databases’,
’/usr/ports/databases/postgresql-devel’]
ensureDirExists(dir)
end

(Why Ruby insists on all functions to be put in a class?)

hack scripts that system admins use/write, it’s pretty nice to be able
to just disregard a specific exception.

Code could break horribly if instructions after raise were executed
at all. It would surprise me if raise didn’t raise.

case something
when foo; x=1
when bar; x=2
else raise SomeError # x is not initialized here,
# it makes no sense to continue
end

···


__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/

Hi,

Not in the current implementation. Besides we should define first
what is going to happen on exceptional situation when exception is
turned off.

You mean if the exception isn’t being ignored? It should be raised as
a normal exception would and left to the current stack.

No. I meant if an exception was ignored, the procedure keeps going
without satisfying assumption. For example,

Dir.mkdir(’/usr’)
Dir.mkdir(’/usr/ports’)
Dir.mkdir(’/usr/ports/databases’)
Dir.mkdir(’/usr/ports/databases/postgresql-devel’)

If you failed to mkdir(’/usr’) for any reason, successive mkdirs might
be meaningless. Maybe I have to check out Common Lisp error system.

						matz.
···

In message “Re: Disabling exceptions - thoughts?” on 02/09/14, Sean Chittenden sean@ruby-lang.org writes:

>> Not in the current implementation. Besides we should define first
>> what is going to happen on exceptional situation when exception is
>> turned off.
>
>You mean if the exception isn't being ignored? It should be raised as
>a normal exception would and left to the current stack.

No. I meant if an exception was ignored, the procedure keeps going
without satisfying assumption. For example,

> Dir.mkdir('/usr')
> Dir.mkdir('/usr/ports')
> Dir.mkdir('/usr/ports/databases')
> Dir.mkdir('/usr/ports/databases/postgresql-devel')

If you failed to mkdir('/usr') for any reason, successive mkdirs might
be meaningless. Maybe I have to check out Common Lisp error system.

Correct.... which'd be the point of the ignore block. Orignally the
thought was to just do Errno::EEXISTS.enable = false, but then someone
had the idea of using a block. Problem with a block would be that
inorder to continue the sequence of commands above, the proc would
have to know what instruction it left off on and resume there. :-/
Not an easy problem and more along the lines of, "gee wiz that'd be
nice while writing chump scripts while I've got my sys admin hat on."
-sc

···

--
Sean Chittenden