title: How to set a default return value in a Rhino Mocks stub
body: <p>Say I want to use Rhino Mocks to generate a stub of the following interface:</p>
  
  <pre><code>public interface IFooBar
  {
    string Foo(string bar);
  }
  </code></pre>
  
  <p>I stub the method <code>Foo</code> in the one-time setup method for my suite of unit tests, along with the following constraints:</p>
  
  <pre><code>  var foobar = MockRepository.GenerateStub&lt;IFooBar&gt;();
    foobar.Stub(f =&gt; f.Foo(Arg&lt;string&gt;.Is.Equal("string1")))
      .Repeat.Any()
      .Return("result1");
    foobar.Stub(f =&gt; f.Foo(Arg&lt;string&gt;.Is.Equal("string2")))
      .Repeat.Any()
      .Return("result2");
    //etc...
  </code></pre>
  
  <p>Currently, if the parameter <code>bar</code> doesn't match any of the constraints above, the method <code>Foo</code> will return <code>null</code> by default. Is there some way I can tell it to return something other than <code>null</code> in these cases (e.g. an empty string or some other arbitrary string)?</p>
  
  <p>I've tried searching the documentation, SO, and elsewhere online but haven't yet found a solution that does what I want.</p>
  
  <p>I tried adding this to the beginning, hoping the subsequent calls to <code>foobar.Stub</code> would "override" this default behavior when the more specific constraints were satisfied:</p>
  
  <pre><code>  foobar.Stub(f =&gt; f.Foo(Arg&lt;string&gt;.Is.Anything))
      .Repeat.Any()
      .Return(string.Empty);
  </code></pre>
  
  <p>Unfortunately that isn't the case; adding the above causes <code>Foo</code> to <em>always</em> return an empty string, as if none of the other <code>Foo.Stub</code> calls ever happened.</p>
  
  <p>I could do the opposite and make the above call <em>after</em> all the other <code>Foo.Stub</code> calls, effectively covering all the remaining possible cases. The downside to this approach is once I do that, I can no longer add any other constraints that may be specific to one particular unit test but not any others.</p>
  
  <p>Worst case scenario, I can extract all the common <code>Foo.Stub</code> calls into a reusable method to call at the beginning of each unit test, followed by more test-specific stubs, and finally the above stub that covers the remaining cases. I'm just wondering if there's a simpler solution.</p>