Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #1645 > unrolled thread

Error codes vs. exceptions

Back to article view | Back to comp.programming

Contents

  Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-05-28 21:15 -0700
    Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-29 00:10 -0500
      Re: Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-05-28 22:41 -0700
        Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-29 01:34 -0500
      Re: Error codes vs. exceptions Adam Skutt <askutt@gmail.com> - 2012-05-29 07:16 -0700
        Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-29 09:45 -0500
    Re: Error codes vs. exceptions Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-05-29 09:08 +0200
      Re: Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-05-31 13:52 -0700
        Re: Error codes vs. exceptions Ian Collins <ian-news@hotmail.com> - 2012-06-01 09:08 +1200
          Re: Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-05-31 22:32 -0700
    Re: Error codes vs. exceptions "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-05-29 09:37 +0200
    Re: Error codes vs. exceptions "io_x" <a@b.c.invalid> - 2012-05-29 10:00 +0200
    Re: Error codes vs. exceptions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-05-29 12:24 +0000
    Re: Error codes vs. exceptions Nobody <nobody@nowhere.com> - 2012-05-30 15:23 +0100
      Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-30 09:40 -0500
        Re: Error codes vs. exceptions Adam Skutt <askutt@gmail.com> - 2012-05-30 08:04 -0700
          Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-30 12:01 -0500
    Re: Error codes vs. exceptions Jeff Flinn <TriumphSprint2000@hotmail.com> - 2012-05-30 14:18 -0400
      Re: Error codes vs. exceptions Patricia Shanahan <pats@acm.org> - 2012-05-30 13:00 -0700
      Re: Error codes vs. exceptions Adam Skutt <askutt@gmail.com> - 2012-05-30 21:25 -0700
    Re: Error codes vs. exceptions Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-05-30 22:44 -0400
      Re: Error codes vs. exceptions Nobody <nobody@nowhere.com> - 2012-05-31 05:04 +0100
      Re: Error codes vs. exceptions Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-06-01 21:44 -0400
    Re: Error codes vs. exceptions "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-06-02 08:39 +0200
      Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-06-02 16:31 -0500
      Re: Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-06-02 15:49 -0700
        Re: Error codes vs. exceptions Ian Collins <ian-news@hotmail.com> - 2012-06-03 11:17 +1200
        Re: Error codes vs. exceptions Rui Maciel <rui.maciel@gmail.com> - 2012-06-03 16:38 +0100
      Re: Error codes vs. exceptions Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-06-03 20:26 -0400
    Re: Error codes vs. exceptions gremnebulin <peterdjones@yahoo.com> - 2012-06-20 12:05 -0700

Page 1 of 2  [1] 2  Next page →

#1645 — Error codes vs. exceptions

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?

[toc] | [next] | [standalone]

#1646

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.

[toc] | [prev] | [next] | [standalone]

#1647

On May 28, 11:10 pm, BGB <cr88...@hotmail.com> 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?

[toc] | [prev] | [next] | [standalone]

#1648

On 5/29/2012 12:41 AM, mike3 wrote:
> On May 28, 11:10 pm, BGB<cr88...@hotmail.com>  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.

[toc] | [prev] | [next] | [standalone]

#1653

On May 29, 1:10 am, BGB <cr88...@hotmail.com> 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

[toc] | [prev] | [next] | [standalone]

#1654

On 5/29/2012 9:16 AM, Adam Skutt wrote:
> On May 29, 1:10 am, BGB<cr88...@hotmail.com>  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.

[toc] | [prev] | [next] | [standalone]

#1649

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

[toc] | [prev] | [next] | [standalone]

#1689

On May 29, 1:08 am, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:
<snip>
> > 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

So does this mean we should have an exception class defined for every
error code, so we can do that "conversion"?

[toc] | [prev] | [next] | [standalone]

#1690

On 06/ 1/12 08:52 AM, mike3 wrote:
> On May 29, 1:08 am, Marcel Müller<news.5.ma...@spamgourmet.com>
> wrote:
> <snip>
>>> 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
>
> So does this mean we should have an exception class defined for every
> error code, so we can do that "conversion"?

That really depends what you intend to do when you catch one.  I tend to 
use an exception type for a family of error codes and include the actual 
code in there.  Most of my simple applications just catch the base 
exception (std::runtime_error), send the result of what() to cerr and exit.

If the application can recover from a specific type of exception, I'll 
catch those a perform whatever recovery or reporting is required.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#1692

On May 31, 3:08 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 06/ 1/12 08:52 AM, mike3 wrote:
<snip>
> > So does this mean we should have an exception class defined for every
> > error code, so we can do that "conversion"?
>
> That really depends what you intend to do when you catch one.  I tend to
> use an exception type for a family of error codes and include the actual
> code in there.  Most of my simple applications just catch the base
> exception (std::runtime_error), send the result of what() to cerr and exit.
>
> If the application can recover from a specific type of exception, I'll
> catch those a perform whatever recovery or reporting is required.
>

I.e. don't make exception classes for every error code but make them
for
a family of error codes?

[toc] | [prev] | [next] | [standalone]

#1650

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

[toc] | [prev] | [next] | [standalone]

#1651

"mike3" <mike4ty4@yahoo.com> ha scritto nel messaggio 
news:4f571f71-55ca-4922-b81b-31f954cac855@kw17g2000pbb.googlegroups.com...
> Hi.
>

if one use exception that one miss the controll of his program

[toc] | [prev] | [next] | [standalone]

#1652

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

[toc] | [prev] | [next] | [standalone]

#1666

On Mon, 28 May 2012 21:15:00 -0700, 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?

It usually means that the condition will rarely occur in practice.

Performance-wise, exceptions are costly if the exception is actually
thrown but free if not thrown, while a status return has a constant
overhead. If the condition rarely occurs, exceptions will work out
cheaper; if the condition is common, returning a status will be cheaper.

But performance is seldom the main issue. If throwing an exception means
that typical code will just wrap the call in a try/catch block, you should
use a status return instead. If typical code will propagate errors up the
call stack, you should probably use an exception.

It's all about code structure. If exceptions make your code cleaner by
reducing the amount of error-handling code, use exceptions. If they just
mean that you replace if/else with try/catch, then use a status return.

[toc] | [prev] | [next] | [standalone]

#1667

On 5/30/2012 9:23 AM, Nobody wrote:
> On Mon, 28 May 2012 21:15:00 -0700, 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?
>
> It usually means that the condition will rarely occur in practice.
>
> Performance-wise, exceptions are costly if the exception is actually
> thrown but free if not thrown, while a status return has a constant
> overhead. If the condition rarely occurs, exceptions will work out
> cheaper; if the condition is common, returning a status will be cheaper.
>

pretty much.

a status code also has the advantage if the return value is used to 
drive logic in the caller, such as knowing when a task has finished, 
when a desired item has been found, ...


> But performance is seldom the main issue. If throwing an exception means
> that typical code will just wrap the call in a try/catch block, you should
> use a status return instead. If typical code will propagate errors up the
> call stack, you should probably use an exception.
>

agreed.

exceptions work much better for transferring control across multiple 
levels of call frames.

if the handler logic is directly in the caller, then it is less convenient.


similarly, there may be the matter of seriousness:
if the situation is "serious" (as-in, could potentially compromise 
correct functioning of the application), then an exception may make more 
sense;
if the situation is something which could be reasonably ignored with 
little or no consequence, then a status code may make more sense.


> It's all about code structure. If exceptions make your code cleaner by
> reducing the amount of error-handling code, use exceptions. If they just
> mean that you replace if/else with try/catch, then use a status return.
>

yep.

this is often what would happen in many cases, using a try/catch as a 
slightly longer, and slower, alternative to an if/else block.

[toc] | [prev] | [next] | [standalone]

#1669

On May 30, 10:40 am, BGB <cr88...@hotmail.com> wrote:
> On 5/30/2012 9:23 AM, Nobody wrote:
>
> > On Mon, 28 May 2012 21:15:00 -0700, 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?
>
> > It usually means that the condition will rarely occur in practice.
>
> > Performance-wise, exceptions are costly if the exception is actually
> > thrown but free if not thrown, while a status return has a constant
> > overhead. If the condition rarely occurs, exceptions will work out
> > cheaper; if the condition is common, returning a status will be cheaper.
>
> pretty much.
>
> a status code also has the advantage if the return value is used to
> drive logic in the caller, such as knowing when a task has finished,
> when a desired item has been found, ...
>

Or you just return the item and avoid the need for status altogether.
Success should be normally be implicit.

> > But performance is seldom the main issue. If throwing an exception means
> > that typical code will just wrap the call in a try/catch block, you should
> > use a status return instead. If typical code will propagate errors up the
> > call stack, you should probably use an exception.
>
> agreed.
>
> exceptions work much better for transferring control across multiple
> levels of call frames.
>
> if the handler logic is directly in the caller, then it is less convenient.

You've said this a whole bunch of times but never once demonstrated
how this is actually true.  I can think of a few cases where it's
true, but they're all pretty contrived.

>
> similarly, there may be the matter of seriousness:
> if the situation is "serious" (as-in, could potentially compromise
> correct functioning of the application), then an exception may make more
> sense;
> if the situation is something which could be reasonably ignored with
> little or no consequence, then a status code may make more sense.
>

As I've explained to you before, it's normally impossible for the
function issuing the error to tell the difference between these two
situations.  Again, you've never once demonstrated how to apply this
reasoning to writing correct, usable code.

Adam

[toc] | [prev] | [next] | [standalone]

#1670

On 5/30/2012 10:04 AM, Adam Skutt wrote:
> On May 30, 10:40 am, BGB<cr88...@hotmail.com>  wrote:
>> On 5/30/2012 9:23 AM, Nobody wrote:
>>
>>> On Mon, 28 May 2012 21:15:00 -0700, 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?
>>
>>> It usually means that the condition will rarely occur in practice.
>>
>>> Performance-wise, exceptions are costly if the exception is actually
>>> thrown but free if not thrown, while a status return has a constant
>>> overhead. If the condition rarely occurs, exceptions will work out
>>> cheaper; if the condition is common, returning a status will be cheaper.
>>
>> pretty much.
>>
>> a status code also has the advantage if the return value is used to
>> drive logic in the caller, such as knowing when a task has finished,
>> when a desired item has been found, ...
>>
>
> Or you just return the item and avoid the need for status altogether.
> Success should be normally be implicit.
>

only if one knows that the function will almost always succeed (IOW: 
succeeding is part of its "definition of operation").

if it may also fail as part of its normal/expected operation, then it no 
longer is so clear cut.


succeeding/failing need not be the same as an error/non-error condition, 
but may be due to other factors (such as an item not already being in a 
list or hash-table and needing to be created, ...).

not all status codes indicate errors as well, and there may actually be 
successful status codes as well (traditionally these are distinguished 
by sign, where <0 means failure, and >=0 means success).


>>> But performance is seldom the main issue. If throwing an exception means
>>> that typical code will just wrap the call in a try/catch block, you should
>>> use a status return instead. If typical code will propagate errors up the
>>> call stack, you should probably use an exception.
>>
>> agreed.
>>
>> exceptions work much better for transferring control across multiple
>> levels of call frames.
>>
>> if the handler logic is directly in the caller, then it is less convenient.
>
> You've said this a whole bunch of times but never once demonstrated
> how this is actually true.  I can think of a few cases where it's
> true, but they're all pretty contrived.
>

I make heavy use of code driven by "predicate functions" (functions or 
methods which return a boolean value to indicate status), which are 
arguably the same sort of thing as what you are arguing against.

it is all a fairly pointless and nit-picky argument at this point.



>>
>> similarly, there may be the matter of seriousness:
>> if the situation is "serious" (as-in, could potentially compromise
>> correct functioning of the application), then an exception may make more
>> sense;
>> if the situation is something which could be reasonably ignored with
>> little or no consequence, then a status code may make more sense.
>>
>
> As I've explained to you before, it's normally impossible for the
> function issuing the error to tell the difference between these two
> situations.  Again, you've never once demonstrated how to apply this
> reasoning to writing correct, usable code.
>

usually a person writing an application will know what the code in the 
thing is going to be doing, as well as the consequences of a given 
operation succeeding or failing.

usually it is also "fairly obvious" from what the function is going to 
be doing as well.


now, I am not opposing using exceptions here, by any means, as there are 
many cases where they do make sense (namely, cases where the situation 
*actually is* unexpected or abnormal).

for example:
running out of memory, or detecting a problem with the heap, is 
something a bit more worthy of an exception.

[toc] | [prev] | [next] | [standalone]

#1672

On 5/29/2012 12:15 AM, 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?...

The best advice I've seen is from 
http://www.boost.org/community/error_handling.html

"The simple answer is: ``whenever the semantic and performance 
characteristics of exceptions are appropriate.''

An oft-cited guideline is to ask yourself the question ``is this an 
exceptional (or unexpected) situation?'' This guideline has an 
attractive ring to it, but is usually a mistake. The problem is that one 
person's ``exceptional'' is another's ``expected'': when you really look 
at the terms carefully, the distinction evaporates and you're left with 
no guideline. After all, if you check for an error condition, then in 
some sense you expect it to happen, or the check is wasted code.

A more appropriate question to ask is: ``do we want stack unwinding 
here?'' Because actually handling an exception is likely to be 
significantly slower than executing mainline code, you should also ask: 
``Can I afford stack unwinding here?'' For example, a desktop 
application performing a long computation might periodically check to 
see whether the user had pressed a cancel button. Throwing an exception 
could allow the operation to be cancelled gracefully. On the other hand, 
it would probably be inappropriate to throw and handle exceptions in the 
inner loop of this computation because that could have a significant 
performance impact. The guideline mentioned above has a grain of truth 
in it: in time critical code, throwing an exception should be the 
exception, not the rule."

Jeff

[toc] | [prev] | [next] | [standalone]

#1673

On 5/30/2012 11:18 AM, Jeff Flinn wrote:
...
> A more appropriate question to ask is: ``do we want stack unwinding
> here?'' Because actually handling an exception is likely to be
> significantly slower than executing mainline code, you should also ask:
> ``Can I afford stack unwinding here?'' For example, a desktop
> application performing a long computation might periodically check to
> see whether the user had pressed a cancel button. Throwing an exception
> could allow the operation to be cancelled gracefully. On the other hand,
> it would probably be inappropriate to throw and handle exceptions in the
> inner loop of this computation because that could have a significant
> performance impact. The guideline mentioned above has a grain of truth
> in it: in time critical code, throwing an exception should be the
> exception, not the rule."
...

*Any* style rule or pattern has a potential for being overridden by
important performance concerns. That does not mean we should not ask
"What is good style?".

I usually prefer exceptions:

1. Exceptions leave the function result available for the natural result.

2. In many languages, exceptions encode more information more directly
than is possible with status codes.

3. Exception processing can be grouped at the end of a block of code,
with the non-exception flow left clear. Status codes tend to result in
interleaving exception handling throughout the main line flow.

Patricia

[toc] | [prev] | [next] | [standalone]

#1679

On May 30, 2:18 pm, Jeff Flinn <TriumphSprint2...@hotmail.com> wrote:
> On 5/29/2012 12:15 AM, 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?...
>
> The best advice I've seen is fromhttp://www.boost.org/community/error_handling.html
>
> "The simple answer is: ``whenever the semantic and performance
> characteristics of exceptions are appropriate.''
>
>
> A more appropriate question to ask is: ``do we want stack unwinding
> here?'' Because actually handling an exception is likely to be
> significantly slower than executing mainline code, you should also ask:
> ``Can I afford stack unwinding here?'' For example, a desktop
> application performing a long computation might periodically check to
> see whether the user had pressed a cancel button. Throwing an exception
> could allow the operation to be cancelled gracefully. On the other hand,
> it would probably be inappropriate to throw and handle exceptions in the
> inner loop of this computation because that could have a significant
> performance impact. The guideline mentioned above has a grain of truth
> in it: in time critical code, throwing an exception should be the
> exception, not the rule."

Except that your guidance doesn't apply here.  Modern C++ runtimes
incur no execution overhead for exception handling unless an exception
is actually thrown.  Since the goal is to terminate the loop entirely,
an exception would be perfectly reasonable in principal. Where it
might unreasonable is if the exception were to be caught and then
computation resumed.  However, it's pointless to assume throwing an
exception will be a problem without measuring.

Adam

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web