In situations such as you are suggestiong below wouldn't regular expressions
just be simpler and cleaner?
Duncan
----- Original Message -----
From: "David Ferguson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 07, 2002 1:57 PM
Subject: Re: [DOTNET] Why does Substring() throw?
> I would never hard code a call like this.
>
> string x = s.Substring(0, 999); // should return "test", not throw
> string x = s.Substring(0, -1 ); // should return Empty , not throw
>
> That would be silly. However, these calls occur due to inline
> computation.
>
> string x = s.Substring(FindStart(...), FindEnd(...));
>
> Let suppose that the function FindEnd() returns -1 because some
> delimiter is not found (like IndexOf()). I would prefer Substring to
> simple return Empty not throw.
>
> If Substring did *not* throw I could do this.
>
> string x = s.Substring(0, s.IndexOf('=') ).Trim().ToUpper();
>
> I could count on Substring returning the *very reasonable* value of
> Empty if the token was not found. Since it does throw, I must do
> this.
>
> int i = s.IndexOf('=');
> string x;
> if (i > 0)
> x = s.Substring(0, i ).Trim().ToUpper();
> else
> x = string.Empty;
>
> My point is...
>
> I see this little 'if' block every time I want to use Substring. It
> would be much more convenient if the Substring simply didn't throw.
> For the same reason that you don't want to be forced to do an 'if'
> block before every division.
>
> Just because everything doesn't throw an exception, that doesn't imply
> that we are returning to the bad old days. Consider
> StreamReader.ReadLine() for example. It returns null if you are at
> the end of the stream. It would not be as convenient to use 'in its
> typical application' if it threw an exception.
>
> Cheers...David
>
> ----- Original Message -----
> From: "Ian Griffiths" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, May 06, 2002 8:26 PM
> Subject: Re: [DOTNET] Why does Substring() throw?
>
>
> "David Ferguson" <[EMAIL PROTECTED]> wrote:
>
> > The fact that Substring() throws if any little parameter is
> > off makes it almost unusable. Don't you think?
>
> I disagree for the examples that you have shown:
>
> > string s = "test";
> > string x = s.Substring(0, 999); // should return "test", not throw
>
> What's wrong with s.SubString(0); ?
>
> I think the use of 999 to indicate "longer than any string could ever
> possibly be" is extremely bad practice. Strings can easily be longer than
> 999 characters. If you mean "from here to the end of the string" then
just
> say so - the String class provides you with a method for doing precisely
> that. Why feed in whacky constants and expect the framework to guess the
> required semantics when you can just say what you mean?
>
>
> > string x = s.Substring(0, -1 ); // should return Empty , not throw
>
> Why would you ever do this? Asking for a string of negative length is
quite
> clearly a programming error, since no such thing can exist. The class is
> simply telling you this rather than attempting to guess what you might
have
> meant if your code hadn't contained that programming error. If you want
an
> empty string, say so.
>
>
>
> > string z = s.Substring(999, 4); // should return Empty , not throw
>
> This is the only case where I can see that it might conceivably be useful
to
> get back nothing, since it would save you from having special handling to
> detect the case when you've run off the end of the string. On the other
> hand, what if running off the end of the string was an error? In that
case
> I *would* require special handling, and would probably be cursing the
string
> class for not doing it for me. And since for all the other cases it makes
> sense to throw an exception for attempting to access a non-existent part
of
> a string, it is consistent for it to do so here.
>
>
>
> > I think it shouldn't throw for the same reason the division
> > by zero doesn't. It is just too much trouble to always test
> > every division.
>
> ...just like it's too much trouble to test the return value from every
> system call? Surely this it is the programmer's job to deal with this
kind
> of thing - to ignore such things would be pure negligence.
>
> If there's an error case, the last thing I want is for the code to
silently
> swallow it and press on regardless. That's how it was in the bad old
days,
> and we changed for a good reason.
>
>
> C# raises a DivideByZeroException if you divide an integer by zero.
Doesn't
> VB? Floating point numbers don't raise an exception admittedly - you get
> Infinity (or NaN if both numbers were zero). But for integers I want it
to
> throw an exception since there is no reasonable integer result for
dividing
> a number by zero. I'm not entirely happy that FP numbers don't throw here
> either actually, mostly because it means that I have to check every time I
> do a divide...
>
> So I disagree entirely with the philsophy behind what you are saying
> (assuming I have understood you correctly) - I think that if the system
were
> silently to swallow errors, it would require *much* more effort on the
> programmer's part to write working code. Of course it would make it much
> easier to write flakey code. But I don't want to write flakey code.
>
>
> > You can't just do simple calculations and get the
> > substring because it might through.
>
> If it throws, it is because you have bad input. This means you should
check
> your input. This is a basic requirement for any piece of code. Failure
to
> check input is probably the single biggest cause of security holes in
> software systems. So I approve of anything that detects bad input and
flags
> it as an error - it keeps me honest (i.e. I have no option but to check my
> input; since I should be doing that anyway if I want my code to be robust,
> it's a good thing that I have no option). I dislike anything that
attempts
> to press on regardless in the fact of manifestly bad input.
>
> For these methods to behave as I believe you are suggesting rather smacks
of
> On Error Resume Next... :-)
>
>
> --
> Ian Griffiths
> DevelopMentor
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
