Returning Error Codes vs. Throwing Exceptions

[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

[Jon Skeet [C# MVP]]

Mark Oueis <ma*******@hotmail.com> wrote:

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.
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.

<snip>
If you chose the latter.
1) What about performance?
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?

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Sriram Krishnan]

I remember Joel Spolsky getting into this debate long back against
exceptions.

--
Sriram Krishnan

http://www.dotnetjunkies.com/weblog/sriram
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Mark Oueis <ma*******@hotmail.com> wrote:

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.

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.

<snip>

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

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?

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Sriram Krishnan <ks*****@NOSPAMgmx.net> wrote:

I remember Joel Spolsky getting into this debate long back against
exceptions.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Nishith Pathak]

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

"Mark Oueis" wrote:

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]

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