Re: Real life cost of using exceptions for control flow?

From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: 06/18/04


Date: Fri, 18 Jun 2004 12:46:21 -0500


"Jerry Pisk" <jerryiii@hotmail.com> wrote in message
news:ucPvcCQVEHA.584@TK2MSFTNGP09.phx.gbl...
>
> "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
>> news:%23%2381brMVEHA.712@TK2MSFTNGP11.phx.gbl...
>> 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
> handled.

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.



Relevant Pages

  • Re: Returning validation result from method: exception, status code...?
    ... Missing Data and Maximum Length Exceeded sounds like Validation to me, ... in this case I would raise exceptions... ... >> Duplicate keys in the database sounds like Exceptions to me. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Collecting and propogating Validation Errors and Warnings in the Business Layer and Data Layer
    ... Normally, we would return on the first failure and report that, but I can see there would be cases for applying all the rules and reporting all the failures. ... We would do this by calling all the appropriate methods in the remote validation object, building up a message to return as failures occur. ... You could either return a null string on success, with the error message as the return value on failure or, as we prefer, to return true on success and throw an exception with the error message assigned to the exception's message property, on failure. ... This latter means that you must configure remoting to return error messages from remote exceptions, of course, in your config file. ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: method signature design question
    ... > to some of the other validation failures I mentioned earlier you can ... that is also why I would model the API to support the business ... > also be provided with the customer service telephone number. ... and the implementation would then have to use exceptions to signal any ...
    (comp.lang.java.programmer)
  • n-tier input and exceptions
    ... validation in the browser is good because it prevents postbacks. ... I was thinking that it would be to throw exceptions ... from the business tier to the GUI tier. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: n-tier input and exceptions
    ... > validation in the browser is good because it prevents postbacks. ... I was thinking that it would be to throw exceptions ... > from the business tier to the GUI tier. ...
    (microsoft.public.dotnet.framework.aspnet)