Returning Error Codes vs. Throwing Exceptions

  • Thread starter Thread starter Mark Oueis
  • Start date Start date
M

Mark Oueis

I've been struggling with this question for a while. What is better
design? To design functions to return error codes when an error
occures, or to have them throw exceptions.

If you chose the former, i have a few questions that need to be
answered.

1) What about functions that need to return a value regardless of the
error. How can they also return an error code unless the function has
"output" parameters. This seems messy and ridiculous.

2) What if the direct caller is not interested in the error. We will
have some kind of error code chain going on. This seems also messy.


If you chose the latter.
1) What about performance?
2) Is there no problem in having too many exceptions, which can cause
the function call to exit from too many places?

I'm sure there are questions concerning these issues that I have not
asked. If you can pose them and answer them I would be greatful.

Thanks a lot

Mark
 
Mark Oueis said:
I've been struggling with this question for a while. What is better
design? To design functions to return error codes when an error
occures, or to have them throw exceptions.
Click to expand...

Generally, throw exceptions if the method can't fulfil what it's meant
to do. In some cases, that will be so common that it should be part of
what it's meant to do, if you see what I mean. For instance, a
TextReader coming to the end isn't unusual, so ReadLine returns null
rather than throwing an exception.

If you chose the latter.
1) What about performance?
Click to expand...

Exceptions are almost entirely free if they're not thrown. If they
*are* thrown, it's certainly more expensive than a return code which is
examined - but you'll have saved time in all the other code where you'd
have been examining "no error" return codes. Exceptions aren't the
performance-killers they're made out to be, unless they're thrown
ridiculously often (like in a tight loop).
2) Is there no problem in having too many exceptions, which can cause
the function call to exit from too many places?
Click to expand...

I don't personally view that as a problem, but I've never been a fan of
the "only return from one place" idea anyway. I find it far easier to
read code which says "exit the method now, in this way" than code which
sets up elaborate flow control solely for the sake of only exiting the
method in one place.
 
Sriram Krishnan said:
I remember Joel Spolsky getting into this debate long back against
exceptions.
Click to expand...

Yes - I read his article very recently. I disagree with him entirely,
and would be interested to see his code - it must either be incredibly
hard to read (with an if block round every significant line of code) or
fail to detect some potential errors.
 
Hi Mark,

first of all, there is a difference between Errorrs and exceptions

Errors occurs due to user mistake. Though the errors can also led an
exception but a programmer should handle this thing through its validation
code.
Exception should only be used for known but preventable situation like out
of memory etc.. Though Microsoft has put his sincere effort in creating
exception classes for every type of exception including that occurs through
error but a good programmer should avoid using these things. Apart from that
the exception handling in itself is a memory intensive and should be avoided
through validation code and other checks .Depending on the requirement you
have to make the additional stuff to minimize the errors

I hope it solves your problem

regards
Nishith
 
Thanks, I think that makes sence. I was leaning towards exception
throwing. It seems much cleaner.

Another thing that has to do with Exceptions. I heard that there is
problem throwing exceptions from within a constructor of a class in
C++. Is this valid in .NET? I heard something along the lines of "half
created object" and "possible memory leaks" for c++. Is there any such
problem in .NET or can I just throw as many exceptions as I want in
the contructor.

Mark
 
Back
Top