Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Error codes vs. exceptions

Reply
Thread Tools

Error codes vs. exceptions

 
 
mike3
Guest
Posts: n/a
 
      05-29-2012
Hi.

I've heard about this, and wonder when is it right to use codes, and
when to use exceptions for reporting errors? I've heard various stuff,
such as that exceptions should only be used to indicate "exceptional"
conditions. Yet what does that mean? I've heard that, e.g. a user
inputting invalid input should not be considered "exceptional", but
something like running out of memory should be. Does this mean that if
we have a program, and we have a "parse()" function that parses a
string input by the user, that this function should return an error
code on parse failure, instead of throwing an exception? Yet we'll
probably also come across places where it's good to use an exception,
in the same program! Which means we get into _mixing error codes and
exceptions_. And what's the best way to do that?

Also, how exactly does one go about determining what is and is not
"exceptional"? Two examples were mentioned of things exceptional and
non-exceptional, but what about something else, like say in a game,
where you have a grid representing a game level, and a request for a
tile of the level is made with a coordinate that is off the map (like
a 64x64 map and something requests a tile at (100, 100).). Would it be
OK for the function working on the tile to throw? Or should it give an
"out of range" error code? And as for that mixing: consider, e.g. C++
and probably many other languages: a function has a single definite
return type. Suppose our grid had a function that extracts an
attribute from a cell. What to do when there's an out-of-bounds
request? Throw exception? See, what I've currently been doing, and
it's probably silly, is to use exceptions when our function needs to
return a value, and error codes when it could otherwise return "void".
This doesn't seem like a good idea. But what to do? Make every
function return an error code, using pointers to output variables to
store output, and only use exceptions for a rare few kinds of "system-
related" error? Yet one can hardly deny the niceness of being able to
say "x = f() + <foo>" (inside a "try" block, perhaps) instead of

if(f(&x) != SUCCESS)
{ // handle error }
x += foo;



Note how we can easily get LONG methods full of repeated code with
error codes (repeated error handlers to handle similar errors at
various function calls calling error-code-emitting functions, if one
wants to be more graceful than simply aborting with an error to the
next level up (which complicates what error codes a function can
return, since it can return its own codes in addition to those
returned by the functions below it, and those may have functions below
THEM, and so on...).). And who likes duplicated code? eww. This seems
a disadvantage of error codes.

Or, and this is what I've been thinking of, use exceptions for every
error that the user does not have control over, like invalid input
strings. Would that be OK or excessive use of exceptions? And if we
are to mix error codes and exceptions, does this mean we should have
the lists of codes and exceptions correspond + a translator to
translate between the two?
 
Reply With Quote
 
 
 
 
BGB
Guest
Posts: n/a
 
      05-29-2012
On 5/28/2012 11:15 PM, mike3 wrote:
> Hi.
>
> I've heard about this, and wonder when is it right to use codes, and
> when to use exceptions for reporting errors? I've heard various stuff,
> such as that exceptions should only be used to indicate "exceptional"
> conditions. Yet what does that mean? I've heard that, e.g. a user
> inputting invalid input should not be considered "exceptional", but
> something like running out of memory should be. Does this mean that if
> we have a program, and we have a "parse()" function that parses a
> string input by the user, that this function should return an error
> code on parse failure, instead of throwing an exception? Yet we'll
> probably also come across places where it's good to use an exception,
> in the same program! Which means we get into _mixing error codes and
> exceptions_. And what's the best way to do that?
>


maybe more like this:
use error codes if it can be reasonably done so;
use exceptions if error codes wont really work.

usually, this means returning an error code if the operation can be
handled as a no-op and otherwise the program can continue as normal
(like, "well, that didn't work").

use an exception if this represents a case where normal operation can no
longer reasonably continue (all action past this point is no longer
likely to be in a valid state, such as detecting that some internal
program state is critically wrong).

if it is not clear to use, probably I would opt with error codes.
(usually, when an exception is needed, it is "fairly obvious").


> Also, how exactly does one go about determining what is and is not
> "exceptional"? Two examples were mentioned of things exceptional and
> non-exceptional, but what about something else, like say in a game,
> where you have a grid representing a game level, and a request for a
> tile of the level is made with a coordinate that is off the map (like
> a 64x64 map and something requests a tile at (100, 100).). Would it be
> OK for the function working on the tile to throw? Or should it give an
> "out of range" error code? And as for that mixing: consider, e.g. C++
> and probably many other languages: a function has a single definite
> return type. Suppose our grid had a function that extracts an
> attribute from a cell. What to do when there's an out-of-bounds
> request? Throw exception? See, what I've currently been doing, and
> it's probably silly, is to use exceptions when our function needs to
> return a value, and error codes when it could otherwise return "void".
> This doesn't seem like a good idea. But what to do? Make every
> function return an error code, using pointers to output variables to
> store output, and only use exceptions for a rare few kinds of "system-
> related" error? Yet one can hardly deny the niceness of being able to
> say "x = f() +<foo>" (inside a "try" block, perhaps) instead of
>
> if(f(&x) != SUCCESS)
> { // handle error }
> x += foo;
>
>
>
> Note how we can easily get LONG methods full of repeated code with
> error codes (repeated error handlers to handle similar errors at
> various function calls calling error-code-emitting functions, if one
> wants to be more graceful than simply aborting with an error to the
> next level up (which complicates what error codes a function can
> return, since it can return its own codes in addition to those
> returned by the functions below it, and those may have functions below
> THEM, and so on...).). And who likes duplicated code? eww. This seems
> a disadvantage of error codes.
>
> Or, and this is what I've been thinking of, use exceptions for every
> error that the user does not have control over, like invalid input
> strings. Would that be OK or excessive use of exceptions? And if we
> are to mix error codes and exceptions, does this mean we should have
> the lists of codes and exceptions correspond + a translator to
> translate between the two?



if the function returns a void, use it to return an error code;
if the function returns a pointer, one can potentially return NULL, and
have another operation to fetch the actual error code (stored off in a
variable somewhere);
if the function returns a number, then it is a little harder, sometimes
it can be ">=0 for success, <0 for error", but if the function may
return the full range, it is a bit harder.

one way I have handled it is to have it be similar to the pointer case,
where a certain value (0 or -1), "may" represent an error, and whether
or not it really does is determined by retrieving the error code.

NaN is also a possible error value for floating-point numbers, but is
rarely used this way.
 
Reply With Quote
 
 
 
 
mike3
Guest
Posts: n/a
 
      05-29-2012
On May 28, 11:10*pm, BGB <(E-Mail Removed)> wrote:
<snip>
> maybe more like this:
> use error codes if it can be reasonably done so;
> use exceptions if error codes wont really work.
>


So does this mean it is OK to use exceptions for errors in, say, a
constructor, regardless of what the error is?
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      05-29-2012
On 5/29/2012 12:41 AM, mike3 wrote:
> On May 28, 11:10 pm, BGB<(E-Mail Removed)> wrote:
> <snip>
>> maybe more like this:
>> use error codes if it can be reasonably done so;
>> use exceptions if error codes wont really work.
>>

>
> So does this mean it is OK to use exceptions for errors in, say, a
> constructor, regardless of what the error is?


potentially.

if for some reason the constructor can't actually do its thing, this may
be a reasonable option.

usually, I prefer "graceful" handling whenever possible, meaning that an
exception would only be used in this case if the produced object would
be invalid and there is no "more graceful" way to handle the situation.

there is no solid rules to define this, and it may need to be evaluated
on a case-by-case basis.
 
Reply With Quote
 
Marcel Müller
Guest
Posts: n/a
 
      05-29-2012
On 29.05.2012 06:15, mike3 wrote:
> I've heard about this, and wonder when is it right to use codes, and
> when to use exceptions for reporting errors? I've heard various stuff,
> such as that exceptions should only be used to indicate "exceptional"
> conditions. Yet what does that mean?


Finally it is up to the programmer to take the decision.
But there are some performance aspects as well as some considerations
about exception safe code.

Depending on your language, throwing an exception could be an expensive
task. C++ is yet mostly harmless, but managed languages like Java or
*.NET create an expensive stack trace at the time of the exception
construction or at throw respectively. So it is in general a bad advise
to throw and catch exceptions over and over in loops.

Furthermore exceptions are an unexpected way of changing the execution
flow. While this is intended in most cases there are some pitfalls. Most
code is not fully exception safe. I.e. is shows undefined behavior if
the exception occur at the evaluation of certain (sub-)expressions.
Writing fully exception safe code can be almost as complicated than
writing thread-safe code.
So in fact you should know which of your functions throw exceptions and
which don't. At the end, the advantage of the exceptions, easy code,
might no longer be that large.


> I've heard that, e.g. a user
> inputting invalid input should not be considered "exceptional", but
> something like running out of memory should be.


Well, I dislike general statements like this.

If a wrong user input causes the normal execution flow to be interrupted
at a certain point, a exception might be quite OK. If the execution
continues with the next input box that might be also become red,
exceptions might not hit the nail on the head. You remember, no catch in
a loop (over the controls).


> Also, how exactly does one go about determining what is and is not
> "exceptional"?


You can't determine this. You have to /define/ this.
What causes your program to abandon normal operation (for a while)?


> non-exceptional, but what about something else, like say in a game,
> where you have a grid representing a game level, and a request for a
> tile of the level is made with a coordinate that is off the map (like
> a 64x64 map and something requests a tile at (100, 100).). Would it be
> OK for the function working on the tile to throw?


Does this abort normal program flow?
What is the proper action to be taken next?

> Or should it give an
> "out of range" error code? And as for that mixing: consider, e.g. C++
> and probably many other languages: a function has a single definite
> return type. Suppose our grid had a function that extracts an
> attribute from a cell. What to do when there's an out-of-bounds
> request? Throw exception?


Unless your semantics have some default value which could be used to
continue processing, you won't come around to abort the execution flow
here. But it could be a good advice to check this before you call any
function that will not work properly. I.e. you could turn the array
bounds condition into a precondition which could be checked by an assertion.


> But what to do? Make every
> function return an error code, using pointers to output variables to
> store output, and only use exceptions for a rare few kinds of "system-
> related" error?


Don't do that. Use exception where they make the code easier to read and
easier to understand. And if you run into performance problems, then
look for a work around. But in C++ this is unlikely as long as you do
not abuse them extensively.
A prominent exception to this rule are APIs that can cross language
boundaries. In this case you mostly have no chance. You need error codes.

Another rule of thumb: if throw and catch are close together with
respect to the call stack it is more likely that an error code fit your
needs. If they are well separated, then exceptions might be preferable.


[...]
> Would that be OK or excessive use of exceptions? And if we
> are to mix error codes and exceptions, does this mean we should have
> the lists of codes and exceptions correspond + a translator to
> translate between the two?


Converting an error code into an exception might be a good idea. But the
other way around is most likely not.

And another rule of thumb: the number of exceptions thrown during the
processing of a complete request should be finite. I.e. it must not
scale with the amount of data processed.


Marcel
 
Reply With Quote
 
Dmitry A. Kazakov
Guest
Posts: n/a
 
      05-29-2012
On Mon, 28 May 2012 21:15:00 -0700 (PDT), mike3 wrote:

> I've heard about this, and wonder when is it right to use codes, and
> when to use exceptions for reporting errors?


Return code should be used under no circumstances.

1. return codes cripple design on the callee's side
2. they cuase massive code replication contaminating the source program on
the client side
3. they are unmaintainable (consider adding/removing a code value)
4. they represent a distributed overhead causing less efficient programs on
most of existing architectures

> I've heard various stuff,
> such as that exceptions should only be used to indicate "exceptional"
> conditions. Yet what does that mean?


Exceptional condition is when normal continuation would be impossible.

As an example consider zero divide. It is exceptional because for x /=0
there is no numeric value y such that y * 0 = x.

> I've heard that, e.g. a user
> inputting invalid input should not be considered "exceptional",


That depends on whether continuation is possible. E.g. an improperly
encoded UTF-8 character may be replaced by '?' or raise an exception
causing the caller to sort things out. The choice depends on the
application. The key question is: who is responsible for recovery?

> but
> something like running out of memory should be. Does this mean that if
> we have a program, and we have a "parse()" function that parses a
> string input by the user, that this function should return an error
> code on parse failure, instead of throwing an exception?


When the result would be invalid, parse should raise an exception, e.g.
Syntax_Error with an appropriate message and error location indication.

> Also, how exactly does one go about determining what is and is not
> "exceptional"?


You look at the contract of the thing. e.g. of operation /. If there is no
way to implement the contract, that is exceptional[*]. Another way to put
it: an exception is to propagate from where there is not enough information
to handle it without crippling the design. When you implement file read
operation. At the file end, you don't know what to do. You cannot continue
reading, so you raise End_Error. The caller should have information how to
react. If it does not, it let the exception propagate or raise another
exception, etc.

-----------
* Exception fixes the contract by adding itself as a possible outcome.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-29-2012
["Followup-To:" header set to comp.lang.c++.]
On Tue, 2012-05-29, mike3 wrote:
> Hi.
>
> I've heard about this, and wonder when is it right to use codes, and
> when to use exceptions for reporting errors?


Are you asking specifically about C++? I will assume "yes", but I get
a bit confused by your crossposting to comp.programming -- what's the
proper use of exceptions varies between languages (and cultures).

> I've heard various stuff,
> such as that exceptions should only be used to indicate "exceptional"
> conditions. Yet what does that mean? I've heard that, e.g. a user
> inputting invalid input should not be considered "exceptional", but
> something like running out of memory should be. Does this mean that if
> we have a program, and we have a "parse()" function that parses a
> string input by the user, that this function should return an error
> code on parse failure, instead of throwing an exception? Yet we'll
> probably also come across places where it's good to use an exception,
> in the same program! Which means we get into _mixing error codes and
> exceptions_. And what's the best way to do that?
>
> Also, how exactly does one go about determining what is and is not
> "exceptional"?


I don't think you should try use the idea of "exceptional" conditions
as a strict rule to apply. IIRC it was something Stroustrup came up with
to explain how he thinks about it, but it's vague; you can debate
what's exceptional or not for years.

Some things are hard to set up general rules for. You have to deal
with them on a case-by-case basis.

> Two examples were mentioned of things exceptional and
> non-exceptional, but what about something else, like say in a game,
> where you have a grid representing a game level, and a request for a
> tile of the level is made with a coordinate that is off the map (like
> a 64x64 map and something requests a tile at (100, 100).). Would it be
> OK for the function working on the tile to throw? Or should it give an
> "out of range" error code?


To me, it has more to do with things like:
- are you going to take steps elsewhere to make out-of-bounds
requests not happen? E.g. document "it's up to the caller
to stay on the map"?
- can it make sense not to handle the error locally?
- would an error code be an unreasonable burden at the calling site,
e.g. you really want to be able to say things like
"get_tile(position).invert();" ?

But it seems you say more or less this below!

> And as for that mixing: consider, e.g. C++
> and probably many other languages: a function has a single definite
> return type. Suppose our grid had a function that extracts an
> attribute from a cell. What to do when there's an out-of-bounds
> request? Throw exception? See, what I've currently been doing, and
> it's probably silly, is to use exceptions when our function needs to
> return a value, and error codes when it could otherwise return "void".
> This doesn't seem like a good idea. But what to do? Make every
> function return an error code, using pointers to output variables to
> store output, and only use exceptions for a rare few kinds of "system-
> related" error? Yet one can hardly deny the niceness of being able to
> say "x = f() + <foo>" (inside a "try" block, perhaps) instead of
>
> if(f(&x) != SUCCESS)
> { // handle error }
> x += foo;
>
>
>
> Note how we can easily get LONG methods full of repeated code with
> error codes (repeated error handlers to handle similar errors at
> various function calls calling error-code-emitting functions, if one
> wants to be more graceful than simply aborting with an error to the
> next level up (which complicates what error codes a function can
> return, since it can return its own codes in addition to those
> returned by the functions below it, and those may have functions below
> THEM, and so on...).). And who likes duplicated code? eww. This seems
> a disadvantage of error codes.
>
> Or, and this is what I've been thinking of, use exceptions for every
> error that the user does not have control over, like invalid input
> strings. Would that be OK or excessive use of exceptions? And if we
> are to mix error codes and exceptions, does this mean we should have
> the lists of codes and exceptions correspond + a translator to
> translate between the two?


As far as I can tell, you think about this pretty much like I do,
except you're still trying to formalize it into some system of rules.
Try not to do that for a while, and see how it feels.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Adam Skutt
Guest
Posts: n/a
 
      05-29-2012
On May 29, 1:10*am, BGB <(E-Mail Removed)> wrote:
> On 5/28/2012 11:15 PM, mike3 wrote:
>
> > Hi.

>
> > I've heard about this, and wonder when is it right to use codes, and
> > when to use exceptions for reporting errors? I've heard various stuff,
> > such as that exceptions should only be used to indicate "exceptional"
> > conditions. Yet what does that mean? I've heard that, e.g. a user
> > inputting invalid input should not be considered "exceptional", but
> > something like running out of memory should be. Does this mean that if
> > we have a program, and we have a "parse()" function that parses a
> > string input by the user, that this function should return an error
> > code on parse failure, instead of throwing an exception? Yet we'll
> > probably also come across places where it's good to use an exception,
> > in the same program! Which means we get into _mixing error codes and
> > exceptions_. And what's the best way to do that?

>
> maybe more like this:
> use error codes if it can be reasonably done so;
> use exceptions if error codes wont really work.


Nonsense. A function should only return a value if the caller can use
the return value to further its own computation. It is very rare for
an error code to be useful to the caller, much less all of the codes
returned by a function. Hence, they should be exceptions because
stack unwinding will be needed.

> usually, this means returning an error code if the operation can be
> handled as a no-op and otherwise the program can continue as normal
> (like, "well, that didn't work").


If the error can and should be treated as a no-op then there is no
reason to return anything at all.

> if it is not clear to use, probably I would opt with error codes.
> (usually, when an exception is needed, it is "fairly obvious").


This is precisely backwards. Return values should have clear,
obvious, and unambiguous usage. If you cannot determine what the
caller would do with the return value, then odds are good they will
"pass the buck" and therefore an exception is the right thing.

> > Or, and this is what I've been thinking of, use exceptions for every
> > error that the user does not have control over, like invalid input
> > strings. Would that be OK or excessive use of exceptions? And if we
> > are to mix error codes and exceptions, does this mean we should have
> > the lists of codes and exceptions correspond + a translator to
> > translate between the two?

>
> if the function returns a void, use it to return an error code;


This is nonsense. I assume you meant, "Change the return type to be
an error code" but I honestly have no clue.

> if the function returns a pointer, one can potentially return NULL, and
> have another operation to fetch the actual error code (stored off in a
> variable somewhere);


This requires either extra parameters or a lot of ugly work to create
thread-safe behavior. Which is why error codes are a bad idea. Using
them simply pollutes calling code for no clear benefit, especially
when stack unwinding is necessary (which is the most common case).

Adam

 
Reply With Quote
 
Adam Skutt
Guest
Posts: n/a
 
      05-29-2012
On May 29, 12:15*am, mike3 <(E-Mail Removed)> wrote:
> Hi.
>
> I've heard about this, and wonder when is it right to use codes, and
> when to use exceptions for reporting errors?


You should almost always use exceptions. The main reason to use error
codes in C++ would be due to compatibility concerns with C frameworks,
or so that C-compatible wrappers can be provided for your C++ code.

I've heard various stuff,
> such as that exceptions should only be used to indicate "exceptional"
> conditions. Yet what does that mean?


It means that anything other than what the function would return if it
completed normally, or did not fail. The question you should ask
yourself is: "What would the function return if it simply could not
fail?" The answer to that question (if any) is the return value.
Anything else should almost certainly be an exception. Anything that
will (really might) require stack unwinding to handle should also be
an exception.

> I've heard that, e.g. a user
> inputting invalid input should not be considered "exceptional", but
> something like running out of memory should be. Does this mean that if
> we have a program, and we have a "parse()" function that parses a
> string input by the user, that this function should return an error
> code on parse failure, instead of throwing an exception?


The result of a parse function is a data structure representing the
parsed input (e.g., a parse tree). If the function cannot produce a
parse tree, and the caller needs a parse tree to continue on their
computation (i.e., failure cannot be sensibly replaced with an empty
tree) than an exception should be thrown.

In this case, it's not necessarily guaranteed that the function that
called parse() will be the function that prompts the user for input.
It's also not guaranteed that prompting the user for replacement input
is possible. If your input comes from a pipe, then you have no way to
prompt the user and only one input. In this case, termination is
likely the only sensible response for the parse failure. An exception
should be used here since stack winding is not only a probable
response, but a likely response, to a parsing failure.

> Yet we'll
> probably also come across places where it's good to use an exception,
> in the same program! Which means we get into _mixing error codes and
> exceptions_. And what's the best way to do that?


Don't. If you must, it is probably best to convert error codes to
exceptions and not vice-versa. This should only come up if you must
interface with legacy systems or C libraries.

>
> Also, how exactly does one go about determining what is and is not
> "exceptional"? Two examples were mentioned of things exceptional and
> non-exceptional, but what about something else, like say in a game,
> where you have a grid representing a game level, and a request for a
> tile of the level is made with a coordinate that is off the map (like
> a 64x64 map and something requests a tile at (100, 100).). Would it be
> OK for the function working on the tile to throw?


Absolutely.

> Or should it give an "out of range" error code?


Doubtful. Code that provided an invalid input either has a bug (so
must be fixed) or received invalid input from the user. In either
case, an exception is better way to structure a response to the error
condition.

> Yet one can hardly deny the niceness of being able to
> say "x = f() + <foo>" (inside a "try" block, perhaps) instead of
>
> if(f(&x) != SUCCESS)
> *{ // handle error }
> x += foo;
>
>
>


Precisely why one shouldn't use error codes.

> Or, and this is what I've been thinking of, use exceptions for every
> error that the user does not have control over, like invalid input
> strings. Would that be OK or excessive use of exceptions?


If I understood you, then buggy functions require program termination
to replace the buggy application[1]. Exceptions will unwind the stack
to terminate the program. Therefore, one should use an exception in
response to invalid input that didn't come from the user.

Though one should also use exceptions to signify invalid input that
did come from the user, because input is rarely accepted in the exact
same function that it is validated.

> And if we
> are to mix error codes and exceptions, does this mean we should have
> the lists of codes and exceptions correspond + a translator to
> translate between the two?


No.

Adam

[1] Typically, a few unique systems aside.
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      05-29-2012
On 5/29/2012 9:16 AM, Adam Skutt wrote:
> On May 29, 1:10 am, BGB<(E-Mail Removed)> wrote:
>> On 5/28/2012 11:15 PM, mike3 wrote:
>>
>>> Hi.

>>
>>> I've heard about this, and wonder when is it right to use codes, and
>>> when to use exceptions for reporting errors? I've heard various stuff,
>>> such as that exceptions should only be used to indicate "exceptional"
>>> conditions. Yet what does that mean? I've heard that, e.g. a user
>>> inputting invalid input should not be considered "exceptional", but
>>> something like running out of memory should be. Does this mean that if
>>> we have a program, and we have a "parse()" function that parses a
>>> string input by the user, that this function should return an error
>>> code on parse failure, instead of throwing an exception? Yet we'll
>>> probably also come across places where it's good to use an exception,
>>> in the same program! Which means we get into _mixing error codes and
>>> exceptions_. And what's the best way to do that?

>>
>> maybe more like this:
>> use error codes if it can be reasonably done so;
>> use exceptions if error codes wont really work.

>
> Nonsense. A function should only return a value if the caller can use
> the return value to further its own computation. It is very rare for
> an error code to be useful to the caller, much less all of the codes
> returned by a function. Hence, they should be exceptions because
> stack unwinding will be needed.
>


not always, it depends.

if you need to unwind the stack either way, then an exception may make
sense. if not, it is probably not a good answer.


>> usually, this means returning an error code if the operation can be
>> handled as a no-op and otherwise the program can continue as normal
>> (like, "well, that didn't work").

>
> If the error can and should be treated as a no-op then there is no
> reason to return anything at all.
>


usually, the error code will indicate a success/failure in this case.

it is often useful to be able to detect "well, that didn't work",
without needing to be like "on no, stuff has gone terribly wrong".


an example is trying to open a file and searching through a path:
the program may try opening the file along various paths, and see if any
of them work;
in this case, we want to know whether or not the file has been opened
successfully, without needing to catch for every iteration of the loop.


>> if it is not clear to use, probably I would opt with error codes.
>> (usually, when an exception is needed, it is "fairly obvious").

>
> This is precisely backwards. Return values should have clear,
> obvious, and unambiguous usage. If you cannot determine what the
> caller would do with the return value, then odds are good they will
> "pass the buck" and therefore an exception is the right thing.
>


often, if one is using an error code, the operation was probably just
handled as a no-op anyways.

one can use an exception if the situation is sufficiently critical to
where the caller merely carrying on as before would not be a desirable
outcome.

very often, there is no reason to care, and it is better to not burden
the caller with the results, except when they actually care whether or
not the operation succeeded.


>>> Or, and this is what I've been thinking of, use exceptions for every
>>> error that the user does not have control over, like invalid input
>>> strings. Would that be OK or excessive use of exceptions? And if we
>>> are to mix error codes and exceptions, does this mean we should have
>>> the lists of codes and exceptions correspond + a translator to
>>> translate between the two?

>>
>> if the function returns a void, use it to return an error code;

>
> This is nonsense. I assume you meant, "Change the return type to be
> an error code" but I honestly have no clue.
>


fair enough, that could have been written better.

I was responding in context of a prior statement, which basically said
that the OP was using return codes in cases where the function would
otherwise return void.

so, in this case, a person might consider using a return code instead of
a void.


>> if the function returns a pointer, one can potentially return NULL, and
>> have another operation to fetch the actual error code (stored off in a
>> variable somewhere);

>
> This requires either extra parameters or a lot of ugly work to create
> thread-safe behavior. Which is why error codes are a bad idea. Using
> them simply pollutes calling code for no clear benefit, especially
> when stack unwinding is necessary (which is the most common case).
>


I disagree that stack-unwinding is the most common case.
IME, no-op is the most common case, and if the error code is even
checked, it is usually done so to determine a success/failure status (so
that the caller logic can determine whether or not to try a different
option, ...).

as for "in a variable somewhere":
typically, this would be an object field or thread-local variable.

an example would be, say, an object with an "obj->getError()" method or
similar, or a "fooGetError()" function which returns the contents of a
TLS variable, ...


then it is thread-safe...

I didn't say here that it would be a global variable or similar, which
wouldn't be thread-safe.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to use file I/o codes with form and controls codes Allen ASP .Net 1 12-03-2007 12:04 AM
Should I use exceptions instead of error codes? mike3 C++ 14 11-17-2007 10:04 PM
Virtual Key Codes, Scan Codes and ASCII Codes in C gj_williams2000@yahoo.co.uk C Programming 2 08-20-2005 11:04 AM
RegEx replace of html codes to ascii codes Greg -- ASP .Net 4 08-09-2005 07:27 PM
Exceptions vs. Error Codes Shane Groff C++ 8 10-10-2004 05:05 PM



Advertisments