Best return type for an exception from a library or data layer

[Guest]

Good points Dave.

I will add that I think saying:

"Exceptions are epxensive"

is practically equivalent to saying:

"Eating at McDonalds will make you fat"

Sure if I eat at McDonalds every day, 5 times day then I am going to end up
fat, but if I am just eating there once a week or once a month then there is
no harm (disregarding food poisoning ). The same goes for exceptions, if
they are occuring infrequently then there is no real performance issue,
however if your design is throwing thousands of exceptions in normal
operation you should rethink it.

It is a lot better in my opinion to throw an exception to alert of a
condition than rely on error codes in most cases, an exception is going to
make sure that the error case is handled by the calling programmer or the app
terminates, minimizing data loss, unlike error codes which do ot have to be
checked.


Mark.
--
http://www.markdawson.org

Hi Bill,

You don't really need experts here. My testing showed 18 exceptions per
millisecond on Vista Beta 2 and 17 on Windows XP (one hyperthreaded CPU;
same machine for both tests; .NET 2.0) using Jon Skeet's program [1]
(already cited in this thread by David Browne). Here is a conversation
discussing my tests results, in its original context:

http://groups.google.com/group/micr...m"+author:dave+sexton&rnum=1#5518b8e9442b4113

If a program throws a single exception, even for input validation (Bruce
Wood mentioned in this thread that he'll use return codes instead), the
performance hit pales in comparison to any of the other consequently
slow-performing design choices you see riddled in common code, such as not
coding long-running processes to run on a background thread, for example.
In other words, performance should probably be the least of a developer's
concern when determining whether an exception should be thrown.

The problem, to paraphrase Jon Skeet, is that a stigma has become of
throwing exceptions so much that people adamantly recommend to avoid
throwing them, probably due to testing in a debugger (Jon's article points
out the difference in performance with and without a debugger attached);
however, this comes with a price by making code that much harder to debug -
debugging is the point of having an exception with a message, stack trace
and corresponding error data in the first place.

I'd say, instead of recommending that exceptions be avoided, recommend that
exceptions should be used where appropriate and that developers should
rethink their design only after seeing any unacceptable performance
degradation in a program while testing (without a debugger attached).
Naturally, as bugs are being fixed, less and less exceptions will be thrown
anyway. But if simply throwing exceptions is causing a program to run
slowly, then the author will probably want to rethink the entire
architecture since any program that is throwing 17000 exceptions per second
has some major architectural flaw, IMO

Anyway, did the MS people ever get back to you with their opinions on this
matter?

--
Dave Sexton

[1] J. Skeet, Exceptions and Performance
http://www.yoda.arachsys.com/csharp/exceptions.html

Tell, ya what. I'll recheck with the framework people on campus that told
me to avoid exceptions--you know, the people that wrote the code. My tests
clearly show that throwing an exception is very expensive in the framework
but I could be wrong. Let's ask another expert...

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)

 

[Cor Ligthert [MVP]]

Earl,

I find those "Best Questions" mostly a kind of foolish.

I live in a city direct at the river Rhine. The best to cross that is a
bridge.
I also live in a country at the North Sea with on the oposite site England,
the best to pass that is by a ship (although for the southern part of
England a train tunnel).
My country is in fact situated at the Atlantic Ocean oposite to America, the
best to cross that is by plane.

Why the hell do you think all those posibilities are made for to report an
exception?

Cor

 

[Earl]

I'm assuming your handling of the English language to mean not what you
wrote, an issue that often causes me much consternation but with much
understanding also. Indeed the answers to this question provided me some
excellent advice and the discourse brought out some of the brighter minds to
weigh in on any of the topics I've ever posted. If it was "foolish" I need
to come up with more questions as foolish to stimulate such discussion.
Nonetheless, the options presented here (if the answer were an "option" at
all) gave me a bright line into the right technique to handle my situation.

 

[David Browne]

I suspect thinking like yours is how we end up with OSs that take
literally several minutes to delete a single file (which should just be a
matter of altering a few bytes on the hdd).

Actually, I agree.

You have to use the appropriate tools for the problem and understand what
the costs of your decisions are. For enterprise applications, you have
ration the performance optimizations you put in.

Any performance optimization costs money. It makes the code more
complicated, so it costs to build. It also increases the cost of
maintenance. If this is not the case, then it's not a performance
optimization: it's just good design. This cost must be justified somehow.

For an OS or a component library where the code will run on many, many
computers and be executed many, many times, the the benefit of a performance
optimization multiplies. For an enterprise application that runs on a few
servers for a few years, and doesn't really need much CPU, there may be no
benefit whatsoever.

David

 

[Registered User]

Tell, ya what. I'll recheck with the framework people on campus that told me
to avoid exceptions--you know, the people that wrote the code. My tests
clearly show that throwing an exception is very expensive in the framework
but I could be wrong. Let's ask another expert...

How about defining what 'expensive' really means before doing the
cost/benefit analysis? That something is expensive does not preclude
it from being extremely useful in certain situations.

regards
A.G.