That really depends on the context.
In your example you're doing nothing else then throwing exceptions in a console
application and, as you yourself state, only at one level deep.
Using a different scenario,
Create an ASP.NET application and let it throw a couple of exceptions around
the call stack. Put a thousand or so worth of user load on the app with ACT
and measure throughput. Then get rid of the exception and do another measure.
You will see a significant increase in the throughput for the application
with less exceptions.
Regardless of the performance issue, there's a semantic and architectural
issue to consider as well.
Exceptions are errors, problems with your code that you couldn't anticipate
writing it. Consider the register user scenario.
1) A user registers for a website.
2) A users login name must be unique.
Implementing this what would be the better way? Trying to persist the user
and throw an exception if it fails or anticipate the problem in advance by
checking the input values and send feedback directly?
I would do this:
public enum RegisterStatus { Ok, LoginNameExists };
public RegisterStatus RegisterUser(User newUser) {
bool loginExists = UserRepository.CheckLoginExists(newUser.LoginName) ;
if ( !loginExists ) {
UserRepository.Register(newUser);
return RegisterStatus.Ok;
}
else {
return Register.LoginNameExists;
}
}
Which IMO is a much clearer. Since we expect users to enter login names that
are already used, that is not an Exceptional case and not really an error
on the users behalf, he couldn't know.
Now in another scenario:
1) We want a email class that are supposed to send emails.
2) When sending an email we expect a correct email address to be given to
us and a message to send.
Now here's a place where exceptions do come in. We expect an email adress
to our function, if we don't get it, an exception should be thrown. In this
case it's all about giving the function enough and correct information to
be able to do its job.
public void SendEmail(string to, string from, string subject, string message)
{
if ( !Validator.IsValidateEmail(to) )
throw new ArgumentException("Not a valid email", "to");
if ( !Validator.AreNotEmptyOrNullString(messsage) )
throw new ArgumentException("I need an email text to send", "message");
// Etc....
}
In this case the user are required to know how an emailadress is written,
we expect a user of an email class to know this. Therefore, not getting a
valid email adress is an Exceptional case.
For some more information about exceptions and performance / scalability,
have a browse over at:
http://msdn.microsoft.com/library/de...netchapt05.asp
--
Patrik Löwendahl [C# MVP]
http://www.lowendahl.net http://www.cornerstone.se Patrik Löwendahl [C# MVP] <pa**************@home.se> wrote:
This is definatly a debated issue. A rule of thumb though. Exceptions
are
Exceptions. They should really only be used for unexpected cases,
like in
valid
input to a method or some infrstructure bits not clicking (like
opening d
atabse
connections etc). Throwing exceptions is a bit expensive and
minimizing t
hrown
exceptions will affect your performance positivly.
Very few applications will actually see any significant performance
degredation due to using exceptions unless they're thrown hundreds of
thousands of times a second (in which case chances are something more
serious is wrong anyway).
See http://www.pobox.com/~skeet/csharp/exceptions.html for more
empirical data on this.
For success/failure indication you should use return values.
No. If a method has failed, it should throw an exception. Return
values are meant to be used (IMO) for the result of the operation of
the method, not whether or not the method has succeeded in doing what
it's been told to do.
The whole "don't use exceptions for control flow" is very wishy-washy
- it doesn't describe what "control flow" really means, and as
exceptions pretty much *always* affect control flow, it's hard to know
what is actually intended.
There are times when it can be tricky to decide whether or not to use
an exception, but in this case (where a large operation needs to be
aborted) an exception sounds just the ticket to me.
