From: Tom Sawyer <transami@...>
Date: 2002-07-19T13:14:27+09:00
Subject: Re: Can you only catch errors one level deep?

On Thu, 2002-07-18 at 19:01, Philip Mak wrote:
> That's why I'm thinking that the ability to only catch errors that are
> one level deep may be useful.

i would agree. the class structure should get very fine grained, almost
to the point of the individual error messages. note, that's probably a
good bit of work, but it would be more flexible that way.

~trasnsami

> 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.
> 

> 
-- 
~transami

  _(")_  dobee dobee do...
   \v/  
   ^ ^