On 2005-03-30, Dennis <De****@discussions.microsoft.com> wrote:
To go farther, why
doesn't a string variable used like b.Trim return nothing when b is nothing
instead of an exception? Everytime you want to trim a string, you have to
check it for being nothing unless you use the Trim function from Microsoft
Visual Basic name space.
That's a good question, actually, and it goes deep into different
approaches to programming, and why some people find much of the VB
namespace along with VB's special-casing of string operators dangerous
while others find it indispensable.
On the one side is the ease-of-use crowd, asking questions like the one
above. If a string is Nothing, there's no reason that string functions
can't return something reasonable. And generally they're absolutely
right, since there's almost always a reasonable semantic equivalence
between Nothing and String.Empty.
On the flipside of the question is a completely different way of looking
at the problem. The question here is why am I dealing with an
uninitialized string, and why is the runtime hiding that from me? If a
string is Nothing when it shouldn't be, that's usually the result of
deeper design issues, and I want to know about it as early in
development as possible. The fact that Trim() hides this fact from me
is an error in design, not a feature.
And in a well-designed program, if a value should never be Nothing, a
check for that is limited to IO classes, not spread throughout the
program.
VB.Classic tended to adhere to the former point of view, C++/Java to the
latter point of view. Since .Net was geared more towards the C++/Java
crowd, the core framework throws on Nothing, while the VB namespace and
VB.Net itself often treats empty strings and null strings equivalently.