On Fri, Jul 19, 2002 at 09:31:02AM +0900, Alan Chen wrote:
> On Fri, Jul 19, 2002 at 09:04:02AM +0900, Philip Mak wrote:
> > The problem with "rescue LoadError" is that it will also catch errors
> > it wasn't meant to! In my case, the file it loaded existed, but
> > requiring that file threw a LoadError because there was some other
> > problem with it. So the "rescue" caught an error it wasn't meant to
> > catch, and just made debugging harder.
> 
> What errors did rescue LoadError catch? Where they derived from LoadError?

It caught a LoadError that was thrown by 'require <file>'. However,
the LoadError was thrown not because <file> couldn't be loaded, but
because <file> had a 'require' statement of its own which threw a
LoadError.

I think the problem is that people see code like this:

begin
	require 'somefile'
rescue LoadError
	# do something
end

and assume that if "# do something" is executed, then it means that
'somefile' did not exist or isn't readable.

I've also ran into a similar problem here:

begin
	someMethod.call(p, *args)
rescue ArgumentError
	p.notify "Too many arguments to command"
end

where the code assumed that ArgumentError is thrown by calling
someMethod with too many arguments, but in fact could be thrown by
something inside someMethod.

That's why I'm thinking that the ability to only catch errors that are
one level deep may be useful.