"Kev" <sp************@nochanceinhelloffindingmehere.comw rote in message
news:uP**************@TK2MSFTNGP06.phx.gbl...
Relying on exceptions to be thrown is sloppy coding in my mind - and not
what they are intended for.
IMHO, you are making too much of this. But since you brought it up, let's
look at your comments...
If you can do a simple check to prevent an exception being raised then do
it.
And do what? The OP's code already has a try/finally. There are a wide
variety of things that could go wrong in just the few lines of code he has,
especially since he's reading the file over a network. How is it better to
add an extra check, just to avoid having the Seek throw an exception, when
all he's likely to do is fall out of the code to the finally anyway.
Why not check for all the other things that could cause an exception?
Exceptions trigger the CPU interrupt line and this causes the CPU to stop
what it is doing, store current info to the stack, handle the exception,
then reload data back off the stack and continue what it was doing (ok,
that was a really rough description - don't quote me exactly). Why halt
the CPU when you can do a simple check that does not have this side
effect?
Because exception handling is for exceptional situations. Not that I really
agree with your characterization of "halting the CPU" anyway, but why would
you slow down the common case, just to save some time in the exceptional
case?
In fact, that's one of the nice things about exception handling. You can
write all of the code as if everything will work fine, not wasting code or
time on expensive checks like retrieving the file length and comparing it to
the minimum required length. After all, the code underlying Seek is going
to have to make that check anyway.
So, you're suggesting that we write the code in a way that forces the exact
same check to happen twice each time through the code, just so that in the
rare case when an exception happens, the exception can be handled more
quickly?
I am not saying do not use try catch - you should use it often, just use
it to handle error situations you can't necessarily check for before the
operation in question.
Well, I simply disagree. IMHO, it's a waste of time checking things that
the code you're calling is going to have to check anyway, especially if your
handling of a failure of the check is identical to how you'd handle an
exception.
"Presumably", and "assured of" are not terms I associate with good
reliable software design.
I used those terms because the code is not mine, and I don't have the full
information regarding the situation in which the code will be used (or even
of other code related to the problem). It makes no sense for you to assume
I'm using those terms as a programming concept, when in fact my use of those
terms has to do with my relationship (or rather, lack thereof) with the OP
and his code.
(Not that I think "assured of" is in any way a negative thing to consider
with respect to code anyway...seems to be, being "assured of" something is a
*good* thing. As in, "I am assured that the compiler will generate the
correct output given my source code").
Pete