Re: Real life cost of using exceptions for control flow?
From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: Fri, 18 Jun 2004 12:46:21 -0500
"Jerry Pisk" <firstname.lastname@example.org> wrote in message
> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
> message news:u9JdnONVEHA.1356@TK2MSFTNGP09.phx.gbl...
>> "Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
>> To throw my opinion in, I think I have to agree with Jon. Designing
>> strictly to avoid exceptions is as mindless as designing to use them in
>> every case. Bending designs so that you have *very* few exceptions,
>> perhaps to the point of only using NullReferenceException,
>> ArgumentNullException, etc, would probably pay greater costs in code
>> complexity than its worth.
> Actualy it will lead to self documented code, as all the checks you'll do
> will explain what the expected input is and how an invalid input is
To be clear here, how are you defining input? Most invalid input is an
exceptional state, atleast during development. Its the applications
responsibility to validate user input and return UI errors based on the
validation, but bad method input *is* exceptional because it breaks
preconditions or invariants that the method defines. Breaking that is
exceptional because it is incorrectly using a method and with a decent
language should be denied as early as possible(compile time when possible).
This is part of the need for a declarative validation framework for C#, to
allow the compiler to determine correctness of arguments and to move as much
of the validation logic *out* of the method and into the calling method as
possible (for a not-null parameter, when you cast the argument to not null
the check would occur, not when the method recieves it).
I don't see how your checks are going to help anything. Frankly, client code
isn't a reliable source of *correct* input, it is the method itself which
defines its own correct input, every time you write semi-correct, totally
unreliable, input analysis around a method or a series of calls to it you
end up with code that defines a new set of input expectations every time. I
wouldn't argue that as being correct.
All an application should do is validate its input, if its correct it
shouldn't have to worry about its underlying input. Of course, I'm not
saying throw exceptions in every case. If a method takes a string with a
query in it and someone passes a null string, IMHO that should simply be a
empty result set or a full result set (depending on the actual semantics of
the method). Its not even an error condition, just a non-existant query, but
that is a particular situation, not a rule. You cannot make general rules
because there is no such thing as a general situation.
> You should write your code that exceptions are just that, exceptional
> situations. Invalid input is not an exception. A lost network connection,
> corrupted file system, or a disk volume filling up are exceptional
> situations, but not user requesting record number abc. So I agree, you
> shouldn't avoid exceptions but you shouldn't misuse them to handle your
> control flow.
I never advocated using them to control flow control(or atleast not the
standard flow control), I am simply stating that the blind "avoid
exceptions" POV is just that, blind.