By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,204 Members | 1,465 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,204 IT Pros & Developers. It's quick & easy.

why does IndexOf still return -1

P: n/a
Wouldn't it make sense if IndexOf just threw a character not found
exception instead of -1?

If -1 is what you were expecting there should be a function ContainsChar
that returns bool.

Thoughts?

Mar 29 '06 #1
Share this Question
Share on Google+
25 Replies


P: n/a
what's the difference between a known exception and a known return based
on the same input data? your logic to handle the error would very
likely be the same...

personally, as long as i know what happens when i give a particular
function some data, i don't care how it handles something like that. it
could return -3.14159 or throw a YoureAFoolForTryingThatException, as
long as its in the documentation.

Gordon Cowie wrote:
Wouldn't it make sense if IndexOf just threw a character not found
exception instead of -1?

If -1 is what you were expecting there should be a function ContainsChar
that returns bool.

Thoughts?

Mar 29 '06 #2

P: n/a
jeremiah johnson wrote:
what's the difference between a known exception and a known return based
on the same input data? your logic to handle the error would very
likely be the same...

personally, as long as i know what happens when i give a particular
function some data, i don't care how it handles something like that. it
could return -3.14159 or throw a YoureAFoolForTryingThatException, as
long as its in the documentation.


It would be "cleaner" as far as separation of the error-handling type of
code goes. Take, for example this function.

int a = SomeString.IndexOf("f");
if (a != -1)
{
int b = SomeString.IndexOf("g");
if (b != -1)
{
int c = SomeString.Substring(a,b).IndexOf("i");
if (c != -1)
{
return(SomeString.Substring(0,c);
}
else
throw InvalidStuff;
}
else
throw InvalidStuff;
}
else
throw InvalidStuff;

phew. now, with exceptions..

try
{
return Somestring.Substring(0,
SomeString.Substring(
SomeString.IndexOf("f"),
SomeString.IndexOf("g")).IndexOf("i"));
}
catch(CharNotFoundException e)
{
throw InvalidStuff;
}

cleaner no? no pesky a,b,c variables either.
Mar 29 '06 #3

P: n/a
It would be "cleaner" as far as separation of the error-handling type of
code goes.
But it's not necessarily an error if the string doesn't contain the
specified character.

try
{
return Somestring.Substring(0,
SomeString.Substring(
SomeString.IndexOf("f"),
SomeString.IndexOf("g")).IndexOf("i"));
}
catch(CharNotFoundException e)
{
throw InvalidStuff;
}


You can still do it this way, Substring shouold throw if you end up
passing -1 to it.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Mar 29 '06 #4

P: n/a

"Gordon Cowie" <go***@dynamicsdirect.com> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...
jeremiah johnson wrote: try
{
return Somestring.Substring(0,
SomeString.Substring(
SomeString.IndexOf("f"),
SomeString.IndexOf("g")).IndexOf("i"));
}
catch(CharNotFoundException e)
{
throw InvalidStuff;
}

cleaner no? no pesky a,b,c variables either.


Sure, as long as you want to call SubString a bunch if times and throw away
the values :)

I prefer the -1 in this case much more. An exception should be used (IMHO)
for "exceptional" circumstances - IndexOf not finding a character is a
"normal" outcome for IndexOf. An execption would be useful if the target
string was null (as it does throw), or if c# strings were kept in native
encodings and they didn't match, etc. Another case is when no "out of band"
sentinal value is possible -- like "int GetNextInt()". Although it's a
matter of taste in most cases, I reckon...
Mar 29 '06 #5

P: n/a
It would also be far more expensive. Exceptions are very expensive and
really, exceptions are for "exceptional" events, things that you normally
would not have control over.

For instance, if you open a socket and the network suddenly shutdown, well,
that is not something your app could have predicted.

"Gordon Cowie" <go***@dynamicsdirect.com> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...
jeremiah johnson wrote:
what's the difference between a known exception and a known return based
on the same input data? your logic to handle the error would very likely
be the same...

personally, as long as i know what happens when i give a particular
function some data, i don't care how it handles something like that. it
could return -3.14159 or throw a YoureAFoolForTryingThatException, as
long as its in the documentation.


It would be "cleaner" as far as separation of the error-handling type of
code goes. Take, for example this function.

int a = SomeString.IndexOf("f");
if (a != -1)
{
int b = SomeString.IndexOf("g");
if (b != -1)
{
int c = SomeString.Substring(a,b).IndexOf("i");
if (c != -1)
{
return(SomeString.Substring(0,c);
}
else
throw InvalidStuff;
}
else
throw InvalidStuff;
}
else
throw InvalidStuff;

phew. now, with exceptions..

try
{
return Somestring.Substring(0,
SomeString.Substring(
SomeString.IndexOf("f"),
SomeString.IndexOf("g")).IndexOf("i"));
}
catch(CharNotFoundException e)
{
throw InvalidStuff;
}

cleaner no? no pesky a,b,c variables either.

Mar 29 '06 #6

P: n/a

"Gordon Cowie" <go***@dynamicsdirect.com> wrote in message
news:uS**************@TK2MSFTNGP09.phx.gbl...
Wouldn't it make sense if IndexOf just threw a character not found
exception instead of -1?
Not necessarily. In many cases it isn't exceptional.
The real answer is an overload with an extra boolean parameter to indicate
whether you want an exception (You could use a different named method
instead but that would clutter the docs and intellisense more)
If -1 is what you were expecting there should be a function ContainsChar
that returns bool.


No because then if you need the index if it is there but it is optional (a
common case) then you must either incur the exception cost or incur the
search cost twice.

Another reason not to throw exception unless something bad has happened is
that it makes debugging harder - typically when I have a problem I would
tell the debugger to stop on exceptions - If there is one for an
unexceptional case then you need separate exception types and you need to
mess around with telling it which ones to stop for and which not and then
just maybe it really is the source ofthe problem one time. If you use the -1
incorrectly it will usually turn up as an array bounds exception.
Mar 29 '06 #7

P: n/a
Peter Rilling <pe***@nospam.rilling.net> wrote:
It would also be far more expensive. Exceptions are very expensive and
really, exceptions are for "exceptional" events, things that you normally
would not have control over.


Exceptions aren't nearly as expensive as most people think. See
http://www.pobox.com/~skeet/csharp/exceptions.html
(In this particular case the performance penalty could be significant
in many programs, but I don't want you follow the myth of exception
performance :)

However, they're still wrong in this situation, because it really isn't
exceptional for a character not to be present in a string - it's
something which is almost always a possibility when you use IndexOf, in
my experience. It's rarely an error condition which would make you want
to unwind the stack a significant distance.

Of course, if Gordon wants to write his own method which throws an
exception instead of returning -1, there's nothing to stop him -
whereas if the method already threw an exception, wrapping it in a
method which returned -1 would incur the performance penalty of the
exception.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 29 '06 #8

P: n/a
Jon,

Note that Exceptions are significantly more expensive in V2, as shown here:

V1.1
Total time taken: 00:00:32.2768033
Exceptions per millisecond: 154

V2
Total time taken: 00:02:59.3157696
Exceptions per millisecond: 27

that means 37 µsecs. per exception, I would say this is more expensive as
some people think ;-)

Willy.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
| Peter Rilling <pe***@nospam.rilling.net> wrote:
| > It would also be far more expensive. Exceptions are very expensive and
| > really, exceptions are for "exceptional" events, things that you
normally
| > would not have control over.
|
| Exceptions aren't nearly as expensive as most people think. See
| http://www.pobox.com/~skeet/csharp/exceptions.html
| (In this particular case the performance penalty could be significant
| in many programs, but I don't want you follow the myth of exception
| performance :)
|
| However, they're still wrong in this situation, because it really isn't
| exceptional for a character not to be present in a string - it's
| something which is almost always a possibility when you use IndexOf, in
| my experience. It's rarely an error condition which would make you want
| to unwind the stack a significant distance.
|
| Of course, if Gordon wants to write his own method which throws an
| exception instead of returning -1, there's nothing to stop him -
| whereas if the method already threw an exception, wrapping it in a
| method which returned -1 would incur the performance penalty of the
| exception.
|
| --
| Jon Skeet - <sk***@pobox.com>
| http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
| If replying to the group, please do not mail me too
Mar 29 '06 #9

P: n/a
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
Note that Exceptions are significantly more expensive in V2, as shown here:

V1.1
Total time taken: 00:00:32.2768033
Exceptions per millisecond: 154

V2
Total time taken: 00:02:59.3157696
Exceptions per millisecond: 27

that means 37 µsecs. per exception, I would say this is more expensive as
some people think ;-)


It's much less expensive than some people think though. There was a
thread on one of the groups a while ago where people were blaming poor
web app performance on the fact that it threw 200 exceptions *per
hour*.

In situations where exceptions are logical to use in the first place
(where usually several levels of stack will be unwound) 37 microseconds
is completely insignificant.

Having said all that, it's surprising just how much slower they are in
2.0...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 29 '06 #10

P: n/a
Inline

****

Willy.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
Note that Exceptions are significantly more expensive in V2, as shown
here:

V1.1
Total time taken: 00:00:32.2768033
Exceptions per millisecond: 154

V2
Total time taken: 00:02:59.3157696
Exceptions per millisecond: 27

that means 37 µsecs. per exception, I would say this is more expensive as
some people think ;-)


It's much less expensive than some people think though. There was a
thread on one of the groups a while ago where people were blaming poor
web app performance on the fact that it threw 200 exceptions *per
hour*.

***
I do remember this thread.

In situations where exceptions are logical to use in the first place
(where usually several levels of stack will be unwound) 37 microseconds
is completely insignificant.

***
Agreed, my point was to illustrate that expensive/inexpensive are relative
terms, and that it's good to know how expensive they are in V2 compared to
V1.

Having said all that, it's surprising just how much slower they are in
2.0...

***
There are a number of CLR services which have become more expensive in V2
(due to security hardening), but this is largely compensated by the
performance gains in other domains.
Mar 29 '06 #11

P: n/a
Willy Denoyette [MVP] <wi*************@telenet.be> wrote:
In situations where exceptions are logical to use in the first place
(where usually several levels of stack will be unwound) 37 microseconds
is completely insignificant.


Agreed, my point was to illustrate that expensive/inexpensive are relative
terms, and that it's good to know how expensive they are in V2 compared to
V1.


That's certainly true - I'll update the page to indicate that when I
get a chance.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 29 '06 #12

P: n/a
> No because then if you need the index if it is there but it is optional (a
common case) then you must either incur the exception cost or incur the
search cost twice.


I see. Also, from reading other's replies. The real issue is the "cost"
related to exceptions. If they were free I think it would make for a
much cleaner coding style. Probably even anywhere a special return code
is returned.

Another negative about -1. It forces IndexOf to return an int, when a
uint would be more appropriate. The max length of the string is
effectively cut in half in order to provide space for the possible -1
result.
Mar 29 '06 #13

P: n/a
One of the bugbears of error handling in any application and any
language is that as an author of a utility function such as IndexOf,
you really have no idea if some situations constitute "exceptions."

Several other posters here have rightly pointed out that "character not
found" may be a perfectly normal situation for many applications. For a
very few applications, it may be a fatal error. As a utility method
writer, you really don't know how your method is going to be used, so
you don't really know what is "exceptional."

Of course, some conditions are obvious exceptions: out of memory,
network going offline... stuff like that. However a good number of
situations could go either way, depending upon the caller.

So, let's say that the writer of IndexOf were to decide in your favour
and make "character not found" an exception, and provide a ContainsChar
method. I would wager that the vast majority of applications calling
IndexOf do not consider "character not found" a fatal error. So, now
you've forced all of those methods to catch an exception, which makes
the flow of code much trickier and makes those apps harder to maintain,
in addition to being much more costly at runtime. (Yes, I've read Jon's
responses, and he is correct, but catching an exception is still
considerably more costly than testing "if (foo.IndexOf('x') < 0)".)

If said caller wants to avoid the exception, you've made him call an
additional method, which ends up searching the string twice: once to
find out if the character is there, and again to get its index.

All of this to cater to the minority of cases in which not finding what
you're looking for is a fatal error.

So the answer: because it's very much simpler for the majority case,
which is that not finding what you're looking for is not a fatal error.
Which, in the end, means that having IndexOf return -1 is simply a
better design.

Mar 29 '06 #14

P: n/a
Gordon Cowie <go***@dynamicsdirect.com> wrote:
No because then if you need the index if it is there but it is optional (a
common case) then you must either incur the exception cost or incur the
search cost twice.
I see. Also, from reading other's replies. The real issue is the "cost"
related to exceptions. If they were free I think it would make for a
much cleaner coding style. Probably even anywhere a special return code
is returned.


No, I don't think so. Not finding a character you've been asked for
just isn't an exceptional condition, IMO. It's almost always a
possibility, and nearly always needs to be handled right then and there
- it would very rarely be appropriate to let an exception bubble up.
Another negative about -1. It forces IndexOf to return an int, when a
uint would be more appropriate. The max length of the string is
effectively cut in half in order to provide space for the possible -1
result.


There are various things already constraining the length of a string:

1) Length is an int property, not a uint one
2) The actual implementation uses the top two bits for flags, so the
actual maximum length of a string is int.MaxValue/2.
3) As the unsigned types aren't CLS-compliant, making String use uint
everywhere would be pretty awkward.

There are plenty of places where I think people use return codes
instead of exceptions inappropriately - but in this case a different
return code is entirely appropriate IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 29 '06 #15

P: n/a
> So the answer: because it's very much simpler for the majority case,
which is that not finding what you're looking for is not a fatal error.
Which, in the end, means that having IndexOf return -1 is simply a
better design.


Yeah it's too bad about the hidden costs associated with exceptions. I
didn't know this before and now I will be incented to avoid them in some
cases.

I don't believe that returning -1 is a very good design. I'm pretty much
against stashing secret codes in the result.

I think an IndexOf that returns a bool and an out parameter would cater
to those wanting to avoid the exception and still not stooping to -1.

bool String.IndexOf(char Char, out int Index)

But it still doesn't allow you to ever pass the result of an IndexOf
directly into a substring, so you would still have pesky extra variables.
Mar 29 '06 #16

P: n/a
In general I agree with you about using "magic return values" to
indicate special situations. However, in this case I think it's the
best design out of the available alternatives.

"Democracy is the worst form of government except for all those others
that have been tried." - Winston Churchill

Mar 29 '06 #17

P: n/a
Post some code Willy, I'm not taking your word for it. We all remember this
thread by the way.

--
Warm Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley 2006
Blog: http://msmvps.com/blogs/Alvin/
-------------------------------------------------------

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:OH**************@TK2MSFTNGP10.phx.gbl...
Jon,

Note that Exceptions are significantly more expensive in V2, as shown here:
V1.1
Total time taken: 00:00:32.2768033
Exceptions per millisecond: 154

V2
Total time taken: 00:02:59.3157696
Exceptions per millisecond: 27

that means 37 µsecs. per exception, I would say this is more expensive as
some people think ;-)

Willy.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
| Peter Rilling <pe***@nospam.rilling.net> wrote:
| > It would also be far more expensive. Exceptions are very expensive and | > really, exceptions are for "exceptional" events, things that you
normally
| > would not have control over.
|
| Exceptions aren't nearly as expensive as most people think. See
| http://www.pobox.com/~skeet/csharp/exceptions.html
| (In this particular case the performance penalty could be significant
| in many programs, but I don't want you follow the myth of exception
| performance :)
|
| However, they're still wrong in this situation, because it really isn't
| exceptional for a character not to be present in a string - it's
| something which is almost always a possibility when you use IndexOf, in
| my experience. It's rarely an error condition which would make you want
| to unwind the stack a significant distance.
|
| Of course, if Gordon wants to write his own method which throws an
| exception instead of returning -1, there's nothing to stop him -
| whereas if the method already threw an exception, wrapping it in a
| method which returned -1 would incur the performance penalty of the
| exception.
|
| --
| Jon Skeet - <sk***@pobox.com>
| http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
| If replying to the group, please do not mail me too

Mar 29 '06 #18

P: n/a
The code is found here...

http://www.pobox.com/~skeet/csharp/exceptions.html

Willy.

"Alvin Bruney - ASP.NET MVP" <www.lulu.com/owc> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
| Post some code Willy, I'm not taking your word for it. We all remember
this
| thread by the way.
|
| --
| Warm Regards,
| Alvin Bruney [MVP ASP.NET]
|
| [Shameless Author plug]
| The Microsoft Office Web Components Black Book with .NET
| Now Available @ www.lulu.com/owc
| Professional VSTO 2005 - Wrox/Wiley 2006
| Blog: http://msmvps.com/blogs/Alvin/
| -------------------------------------------------------
|
|
|
| "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| news:OH**************@TK2MSFTNGP10.phx.gbl...
| > Jon,
| >
| > Note that Exceptions are significantly more expensive in V2, as shown
| here:
| >
| > V1.1
| > Total time taken: 00:00:32.2768033
| > Exceptions per millisecond: 154
| >
| > V2
| > Total time taken: 00:02:59.3157696
| > Exceptions per millisecond: 27
| >
| > that means 37 µsecs. per exception, I would say this is more expensive
as
| > some people think ;-)
| >
| > Willy.
| >
| >
| > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
| > news:MP************************@msnews.microsoft.c om...
| > | Peter Rilling <pe***@nospam.rilling.net> wrote:
| > | > It would also be far more expensive. Exceptions are very expensive
| and
| > | > really, exceptions are for "exceptional" events, things that you
| > normally
| > | > would not have control over.
| > |
| > | Exceptions aren't nearly as expensive as most people think. See
| > | http://www.pobox.com/~skeet/csharp/exceptions.html
| > | (In this particular case the performance penalty could be significant
| > | in many programs, but I don't want you follow the myth of exception
| > | performance :)
| > |
| > | However, they're still wrong in this situation, because it really
isn't
| > | exceptional for a character not to be present in a string - it's
| > | something which is almost always a possibility when you use IndexOf,
in
| > | my experience. It's rarely an error condition which would make you
want
| > | to unwind the stack a significant distance.
| > |
| > | Of course, if Gordon wants to write his own method which throws an
| > | exception instead of returning -1, there's nothing to stop him -
| > | whereas if the method already threw an exception, wrapping it in a
| > | method which returned -1 would incur the performance penalty of the
| > | exception.
| > |
| > | --
| > | Jon Skeet - <sk***@pobox.com>
| > | http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
| > | If replying to the group, please do not mail me too
| >
| >
|
|
Mar 29 '06 #19

P: n/a
<"Alvin Bruney - ASP.NET MVP" <www.lulu.com/owc>> wrote:
Post some code Willy, I'm not taking your word for it. We all remember this
thread by the way.


As Willy posted, it's the code at the link I posted before. Here are my
results:

1.1:
Total time taken: 00:00:42.7343750
Exceptions per millisecond: 117

2.0:
Total time taken: 00:03:57.1093750
Exceptions per millisecond: 21

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 29 '06 #20

P: n/a
> In general I agree with you about using "magic return values" to
indicate special situations. However, in this case I think it's the
best design out of the available alternatives.


I'm going to go out on a limb and postulate that any design involving
returning a special code that is the same datatype as the normal result
to not be the best design.

It's the oldest design. Maybe the simplest. Definitely the widest in use.

C# is full of great design philosophies that we conform to in the
journey to write better code. I really don't have a huge problem with
the way IndexOf works (I hardly use it), just using it to spur
discussion as I thought there would be interest from some "code purist"
C# lovers here.
Mar 30 '06 #21

P: n/a
Well, then we disagree on the definition of "best". :-)

I used to be a code purist, but in my old age I've become a pragmatist.
Sometimes conceptually pure frameworks lead to ugly, twisted
application code. Sometimes hacks in the underlying framework lead to
simpler applications (and thus cheaper to build and maintain).

Most of the time neither of these applies: elegant frameworks lead to
simple, elegant application code. However, 'tis not always so.

These days, my definition of "best design" = "inexpensive to maintain".
Other definitions may vary. :-)

Mar 30 '06 #22

P: n/a

"Gordon Cowie" <go***@dynamicsdirect.com> wrote in message
news:OH**************@tk2msftngp13.phx.gbl...
No because then if you need the index if it is there but it is optional
(a common case) then you must either incur the exception cost or incur
the search cost twice.

I see. Also, from reading other's replies. The real issue is the "cost"
related to exceptions. If they were free I think it would make for a much
cleaner coding style. Probably even anywhere a special return code is
returned.


try
{
x = s.IndexOf('x');
}
catch( Exception e )
{
// how is it clear that this relates to the indexing?
}

v

x = s.IndexOf('x');
if( x < 0 )
{
}
else
{
}

Worse yet you just know that you are going to find a load of code like:

try
{
x = s.IndexOf('x');
}
catch {}
Another negative about -1. It forces IndexOf to return an int, when a uint
would be more appropriate. The max length of the string is effectively cut
in half in order to provide space for the possible -1 result.


uint is not CLSCompliant so it's never going to happen.

If you have strings of over 2GB then indexing will be the least of your
problems.

P.S. In my opinion they should at least have provided

public const int NotFound = -1;

I'm not a fan of magic numbers even for error returns.

Mar 30 '06 #23

P: n/a
Gordon Cowie <go***@dynamicsdirect.com> wrote:
In general I agree with you about using "magic return values" to
indicate special situations. However, in this case I think it's the
best design out of the available alternatives.


I'm going to go out on a limb and postulate that any design involving
returning a special code that is the same datatype as the normal result
to not be the best design.

It's the oldest design. Maybe the simplest. Definitely the widest in use.

C# is full of great design philosophies that we conform to in the
journey to write better code. I really don't have a huge problem with
the way IndexOf works (I hardly use it), just using it to spur
discussion as I thought there would be interest from some "code purist"
C# lovers here.


Let's consider another example - TextReader.ReadLine. Should that throw
an exception instead of returning null when it has reached the end of
the stream? That would break the common idiom of:

string line;
while ( (line=reader.ReadLine()) != null)
{
...
}

- and it would break it without any significant benefit in my opinion.

If indeed using a special return code *is* the simplest design - and
ends up with the simplest client code - then that's probably the best
design, IMO. If most uses of the call work most easily when IndexOf
returns -1, where is the actual benefit of making it throw an exception
or forcing the use of an out parameter?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 30 '06 #24

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Gordon Cowie <go***@dynamicsdirect.com> wrote:
[snip]
Let's consider another example - TextReader.ReadLine. Should that throw
an exception instead of returning null when it has reached the end of
the stream? That would break the common idiom of:

string line;
while ( (line=reader.ReadLine()) != null)
{
...
}


[snip]

Admit it! Many of us would prefer the good old C/C++ idiom:

while( (line = reader.ReadLine()) )
{
//....
}

Yes - I know about the == bugs and I've done it myself but they always show
up before delivery so I'm willing to take my chances.

NB I always bracket the expression in these cases to indicate that I really
mean it. If I had my way the compiler would not warn if the expression was
bracketed.
Mar 30 '06 #25

P: n/a
Nick Hounsome wrote:
[snip]

Admit it! Many of us would prefer the good old C/C++ idiom:

while( (line = reader.ReadLine()) )
{
//....
}
Well, "many" may do, but I know I wouldn't.
Yes - I know about the == bugs and I've done it myself but they always show
up before delivery so I'm willing to take my chances.
I prefer the explicit nature of things myself.
NB I always bracket the expression in these cases to indicate that I really
mean it. If I had my way the compiler would not warn if the expression was
bracketed.


I seem to remember that GCC does that...

Jon

Mar 30 '06 #26

This discussion thread is closed

Replies have been disabled for this discussion.