[Mono-dev] Error in UnixGroupInfo

[Jonathan Pryor]

On Thu, 2007-06-21 at 13:58 +0200, Rolf Bjarne Kvinge wrote:
> > Con: All but one property would now be able to throw an exception,
> > while previously they wouldn't.  So currently-working "broken" code like
> > this: 
> > 	UnixGroupInfo g = ...
> > 	foreach (UnixUserInfo u in g.GetMembers ()) {
> > 		Console.WriteLine ("User: {0}; Home: {1}",
> > 			u.UserName, u.HomeDirectory);
> > 	}
> > 
> 
> Maybe I missed something, but won't g.GetMembers () throw an 'invalid
> username' exception now for this scenario?
> 
> In which case this code is already broken and will continue to be broken
> with this solution...

Yes, and no.  It's a matter of what the resulting exception is.

Currently, the above will generate an ArgumentException on
mis-configured systems.  Certainly this isn't the most desirable
exception type to be throwing, but at least the developer can narrow
down the problem.

Solution (2) would throw either a NullReferenceException -- implying
that the developer did something wrong when they really didn't -- or it
would throw an InvalidOperationException.  As exceptions go,
InvalidOperationException is certainly better than NRE, but it still
implies that the developer did something wrong when, at a cursory glance
at the code, they didn't.

A NRE or IOE could be avoided by adding an IsValid property to
UnixUserInfo, but now this bloats the API.  If there were other
scenarios where it would be useful to deliberately create an "invalid"
UnixUserInfo instance, that would be great, but I think that's already
supported through the UnixUserInfo(Mono.Unix.Native.Passwd) constructor
instance (which allows the UnixUserInfo to return arbitrary information
-- and using this constructor would be the easiest way to get
NullReferenceException behavior from chained use of the UnixUserInfo
properties, but again, NRE's aren't very nice).

 - Jon