From: nathaniel@...
Date: 2003-02-06T12:42:16+09:00
Subject: Re: Return values from assertions

Matt Armstrong [mailto:matt@lickey.com] wrote:

> I've often wondered how useful assert_no_exception actually 
> is, given that the framework reports uncaught exceptions anyway.

The only advantage I see is if you wanted a particular exception that
could be thrown to show up as a failure instead of an error. This can be
particularly useful if you want to add an assertion message if/when that
exception is thrown.


> > What I'm thinking at the moment is:
> >
> > 1) Leave in the return value from #assert_raises.
> > 2) Remove the return value from #assert_match.
> > 3) In general, avoid returning (documented) values from assertions.
> >
> > To clarify #3, I don't plan on returning nil from all the
assertions, 
> > but I do plan on not explicitly returning something useful from
them, 
> > and saying that if you depend on something that is returned as a
side 
> > effect, too bad for you if it changes.
> 
> Given that I've only ever meaningfully used the return value 
> of assert_raises, that sounds good to me.  #3 is not my style 
> (I'd just return nil everywhere) but it is hard to come up 
> with any real reason to go one way or the other.

<to the list> Is there a good rule of thumb for what methods should do
when they don't have a useful value to return? I can't remember seeing
any code that was careful to always return nil, but that could just be
my limited reading.


Nathaniel

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI