Error handling idioms

[Gavin Deane]

GavinDeanewrote:

You said it yourself.

So that error handling and normal program logic are not intermingled.

There are too many vaguely defined terms here. Let's fix that. For the
remainder of this post I will use the following definitions.

A "failure" is when you try something and don't get the right result.
"Failures" fall into two categories. Using examples from up-thread:
A "common occurance" is a failure like the user spelling their
password incorrectly.
An "error" is a failure like finding incorrectly formatted data in a
file my program created.

"Normal program logic" is the path taken in the absence of any
failures.

Using those definitions, I use exceptions when the design calls for
handling of a particular failure to be separated from normal program
logic, regardless of whether that failure is an error or a common
occurance. I don't do that because I have a penchant for exceptions
and I want to use them wherever possible. I do it because, in desiging
my software, I have already identified the points where failuire
handling needs to be separated from normal program logic.

I don't know how to make the decision based on whether a particular
failure is a common occurance or an error, because I don't know what
are the generic cirteria that distinguish the two across all
programming problems. That is why I was only able to define "error"
and "common occurance" above by reference to existing examples. But my
definitions above do not help me decide whether a particular failure
is an error or a common occurance when I am tackling a *new* problem.

Two examples of things I am unlikely to do:

Introduce branches and conditions into a group of functions so I can
pass a return code indicating failure several layers up the call stack
when I could get there in one go with an exception, even if someone
argues that that failure is a common occurance.

Throw and catch an exception within the same function [*] if a
particular failure occurs, even if someone argues that that failure is
an error. (Although I suppose I might consider doing this if it's a
vast, monolithic, maintenace nightmare of a function where it is
possible to be very distant from the detection of the failure yet
still within the same function. In an ideal world such things should
never happen, but in the real world they do).

Second, there's the performance issue...exceptions can throw slow and do
in at least one common implementation.

Indeed, but that's an orthogonal consideration as susceptible to
premature optimisation as any other performance issue.

Gavin Deane

 

[Noah Roberts]

There are too many vaguely defined terms here. Let's fix that. For the
remainder of this post I will use the following definitions.

A "failure" is when you try something and don't get the right result.
"Failures" fall into two categories. Using examples from up-thread:
A "common occurance" is a failure like the user spelling their
password incorrectly.
An "error" is a failure like finding incorrectly formatted data in a
file my program created.

"Normal program logic" is the path taken in the absence of any
failures.

change failures to errors here. Trying something and failing is not
always an error and thus falls into the "normal program logic" to handle.

 

[Gavin Deane]

We'll keep the three definitions above.

change failures to errors here. Trying something and failing is not
always an error and thus falls into the "normal program logic" to handle.

You've missed the point of why I provided these definitions. My
argument needs a name for the concept of the path taken in the absence
of any failures. If you don't like "normal program logic" as the name
for that concept that's fine, I'll call it something else. How about
"non-failure program logic"? It's a bit more cumbersome, but I do need
a name for the concept.

Change "normal program logic" to "non-failure program logic" in my
previous post.

Gavin Deane

 

[Noah Roberts]

We'll keep the three definitions above.


You've missed the point of why I provided these definitions.

No, I think you missed the point. Simple failure belongs in program
logic. X != expected value is not an exceptional event. User entering
the wrong password...also not an error. These are failures and belong
in the normal program flow.

 

[Gavin Deane]

No, I think you missed the point. Simple failure belongs in program
logic. X != expected value is not an exceptional event. User entering
the wrong password...also not an error. These are failures and belong
in the normal program flow.

Depends what you mean by "normal". I meant something else. I was aware
that I was using the phrase "normal program logic" to mean something
very specific, which is why I was careful to define what I meant.

You tried to tell me that my definition of "normal program logic" was
incorrect. That was a non sequitur because, for the purposes of my
argument, "normal program logic" was a term *I* was defining.

Recognising that despite my careful definition there was scope for
confusion because I had used a term that already meant somthing else
to you, I changed the name of the concept from "normal program logic"
to "non-failure program logic". The definition is the same but
hopefully the new name is unfamiliar and so you have no preconceived
ideas about its meaning.

So, if you want to understand my argument, re-read my post up-thread,
substituting "non-failure program logic" for "normal program logic"

Gavin Deane

 

[Noah Roberts]

Depends what you mean by "normal". I meant something else. I was aware
that I was using the phrase "normal program logic" to mean something
very specific, which is why I was careful to define what I meant.

You tried to tell me that my definition of "normal program logic" was
incorrect. That was a non sequitur because, for the purposes of my
argument, "normal program logic" was a term *I* was defining.

Shen me? Wo bu zhi dao ni gao su wo.

 

[Gavin Deane]

I posted a reply yesterday but it's not appeared yet. A delay that
long between posting and seeing the post is unusual through Google
Groups so I'll try again. Apologies for the double post if the first
one eventually appears.

Since I do not subscribe to the point you question, I might not be
well-posed to answer your call. I will try nonetheless. I know the
following reasons:

a) Code is meant to communicate intent. Since, for better or worse,
exceptions have been popularized by the powers that be as a mechanism for
error handling only, it is wise to follow that rule. Violations are bound
to create misleading expectations in those reading the code.

I absolutely agree with the principle of code communicating intent.
However, for someone to say "exceptions are for error handling only"
is meaningless without a definition of "error". Without that, there is
no common understanding of intent that can be mis-communicated. "Your
code confused me for a while there because you were using an exception
for a situation that wasn't an error" or "Your code confused me
because you used something other than an exception to handle that
error" are only valid compliants if we all have the same
understanding, generically, of what is and what isn't an error.

The question I have is, what are the generic properties or criteria,
applicable across all programming problems, that distinguish events
for which exceptions are appropriate from events for which exceptions
are not appropriate. It is the lack of any answer to *this* question
that means I don't find a statement like "exceptions are for error
handling only" at all useful, particularly when trying to give general
advice on when to use exceptions to someone learning the language.

The only answer prevalent seems to be "an error is any situation that
isn't normal" which moves us no further. It just changes the question
from "Please define error" to "OK, error == !normal. Please define
normal".

b) Similarly, because of the wide-spread perception that exceptions are
rare, many compilers tend to heavily optimize for the non-throw path of
control flow. Thus, using exceptions can be quite expensive.

I don't disagree there either. And I don't think my approach leads to
a particularly more widespread use of exceptions. The difference is
that it's an approach based on concepts I understand rather than
concepts I don't understand and nobody can explain to me. My point is
not so much about when to use exceptions, but more about how to
explain to someone who doesn't know, when to use exceptions.

There is the issue of premature optimisation too of course. In
general, I won't worry about the performance hit unless and until it's
shown to be a problem. If exceptions are known to be quite expensive,
deciding in advance not to use them all over the place is probably not
premature optimisation - it's sensible. But as I say, I'm not
suggesting using them all over the place.

c) The try-throw-catch mechanism is a glorified goto, except that it is even
worse: with a goto, at least you know where you jump. The dangers posed by
exceptions for maintainable programming are quite similar to those of goto.
Try-throw-catch introduces global dependencies in your code, i.e., it
becomes hard to understand the program in local terms, like what is going
on in the few lines on my screen. Therefore, strict coding guidelines
should accompany the use of exceptions. The rule to use them for
error-reporting only is a successful proposal in this regard. Weakening it
to: "write code that is easy to understand" is too permissive and will lead
down a slippery slope (as it does with goto). However, it is true that a
restrictive criterion can be inconvenient at times. This is just the price
you have to pay to confine the threat.

Bear in mind that my criterion for considering exceptions is that I
have already identified a need to get from one point in the program
structure to some other non-local point in the program structure. It
is already a given that you will not be able to fully understand this
part of the program in local terms by looking at the few lines on your
screen. The only question that remains is "Since I have to jump from
this point here to that point over there, what is the cleanest way of
doing that?". Options might be, for example, throw an exception,
introduce return codes to a family of functions, goto, refactor the
code. I say, if the answer is "exceptions are cleanest" then use
exceptions. I finish the decision process and it doesn't matter that
nobody can explain to me what's an "error" and what's "normal" because
I haven't had to make any decisions based on that distinction.

It is because I generally try and avoid jumping around the program
structure like this (for the reasons you mention) that I end up using
exceptions rarely.

Gavin Deane

 

[Kai-Uwe Bux]

I posted a reply yesterday but it's not appeared yet. A delay that
long between posting and seeing the post is unusual through Google
Groups so I'll try again. Apologies for the double post if the first
one eventually appears.


I absolutely agree with the principle of code communicating intent.
However, for someone to say "exceptions are for error handling only"
is meaningless without a definition of "error". Without that, there is
no common understanding of intent that can be mis-communicated. "Your
code confused me for a while there because you were using an exception
for a situation that wasn't an error" or "Your code confused me
because you used something other than an exception to handle that
error" are only valid compliants if we all have the same
understanding, generically, of what is and what isn't an error.

Actually, there is no need for a definition of "error" to make the rule

Use exceptions for error-handling only

work. If everybody obeys that rule, the use of an exception in the code will
communicate that the author considered the condition an error. Whether you
agree with that assesment or not is immaterial, the communication of intent
was nonetheless successful.

One could even go so far to say that we need a language feature reserved for
error handling precisely because reasonable people can disagree on what an
error is so that a programmer can express his assesment of a particular
situation (i.e., whether a certain condition is an error or not) in code.
If we had a clear-cut criterion, we would not need to communicate that X is
an error because the reader could figure that out by himself.

All that is needed is that error is a concept that can be understood and
agreed/disagreed upon in examples and concrete cases: it is always concrete
cases about which we communicate when writing code.

The question I have is, what are the generic properties or criteria,
applicable across all programming problems, that distinguish events
for which exceptions are appropriate from events for which exceptions
are not appropriate. It is the lack of any answer to *this* question
that means I don't find a statement like "exceptions are for error
handling only" at all useful, particularly when trying to give general
advice on when to use exceptions to someone learning the language.

The only answer prevalent seems to be "an error is any situation that
isn't normal" which moves us no further. It just changes the question
from "Please define error" to "OK, error == !normal. Please define
normal".

"Error" is a concept that I would only illustrate by examples. I cannot
really define the notion of a smooth texture. But I can recognize one, and
I am confident that I could teach someone to recognize smooth textures.
Definitions are not the only way to introduce concepts. What about "error"
is it that gives you trouble? Could it be that you are reading too much
into the recommendation. The way I understand it (as far as communicating
intend goes) is:

Use exceptions to make clear that the handled condition is considered
an error.

That does not pre-suppose that there is a definition of "error". It just
pre-supposes that the addressee of the recommendation has an understanding
of what _he_ considers an error _within_ the context of a particular
program. Then he uses exceptions to signal to others that condition X
counts as an error in the context of program Y.


[(b) snipped for lack of disagreement]

Bear in mind that my criterion for considering exceptions is that I
have already identified a need to get from one point in the program
structure to some other non-local point in the program structure. It
is already a given that you will not be able to fully understand this
part of the program in local terms by looking at the few lines on your
screen. The only question that remains is "Since I have to jump from
this point here to that point over there, what is the cleanest way of
doing that?". Options might be, for example, throw an exception,
introduce return codes to a family of functions, goto, refactor the
code. I say, if the answer is "exceptions are cleanest" then use
exceptions. I finish the decision process and it doesn't matter that
nobody can explain to me what's an "error" and what's "normal" because
I haven't had to make any decisions based on that distinction.

It is because I generally try and avoid jumping around the program
structure like this (for the reasons you mention) that I end up using
exceptions rarely.

The question here is not so much whether this decision making process works
for you. It is more about whether recommending this decision making process
to others is wise. It could be that your personal understanding of what
is "cleanest" leads you to use exceptions only rarely. However, I wonder
whether others programmers understanding of what counts as clean is
sufficiently similar and will prevent them from using exceptions
dangerously often. The problem is, of course, that we make decisions about
exceptions many times in a larger program; each decision is well-justified
at the time; but still they might add up to a horrible mess in the end.


Ultimately, I feel that no rule can replace wisdom and experience. I like to
experiment with programming styles, and I confess to trying out gotos and
exceptions in places considered inappropriate by most programmers.
Sometimes I end up with a convoluted result and it is precisely in those
cases where I learn something (assesing which choices were bad). I think,
we should not try to protect beginners from such mistakes by giving them
rules to follow. Maybe, it would be better to tell them that they need a
critical attitude toward their code and should be prepared for major
rewrites as their skills mature over time.


Best

Kai-Uwe Bux

 

[JohnQ]

No, I think you missed the point. Simple failure belongs in program
logic. X != expected value is not an exceptional event. User entering
the wrong password...also not an error. These are failures and belong in
the normal program flow.

OK, I'll go out on a limb and add a few thoughts (since the thread at this
has had me sitting here thinking about the issues for a few minutes now)...

Is getting invalid input data from a user an error? Well it depends on your
definitions in the area of error processing. Someone may say it is not an
"error" because they reserve that term for another category of conditions.
They may say it is "simple failure" or something. I personally would
categorize it as "user error" and handle it appropriately (dialog warning
box, lockout after 3 unsuccessful tries, etc.). I'm OK with calling all
kinds of things like that "errors" as long as the category or type of the
error is given also: "user error", "user input error", "assertion error",
etc.

Now let's example with a contrasting kind of error: a program requiring a
..ini file from which to read initialization information finds that the file
does not exist (!). The program gets installed with a default .ini file and
we know that so something is severely amuck (perhaps the user was mucking
around in folders where he should not have been and, yes, deleted the
file!). Well obviously the program cannot startup without the .ini file.
That it is missing in action is exceptional.

In the above example, I tried to convey a "severe error" or something
"exceptional", very "not expected nor likely". Well it's obvious then C++
exceptions should be used right? I mean, we have an exceptional scenario and
a set of mechanisms in C++ has the same name ("exceptions") so surely that
is what we want to use in this scenario. Well if that's the error processing
design you've chosen, by all means use it if you want to, but return codes
would work just as well. The point I am trying to make is that, I think, the
choice made to name the new error processing mechanism in C++ was not
necessarily chosen to reflect under what conditions it should be used. Sure,
the "can't return an error code from a constructor" scenario is a tricky
problem to solve, hence it is exceptional, and that's probably how the
mechanism got its name. Realize though that the mechanism was pretty much
required to make the language work cleanly (surely there are alternatives
but the "non local goto" was seen as the best solution and it's not like
there wasn't prior common practice aka setjmp/longjmp).

Making a long story short: having exceptional circumstances, such as the
..ini file missing, does not map onto "that's what C++ exceptions are for".
If the situation warrants it, such as constructor error, or if you deem the
mechanisms otherwise worthy, go ahead and use them for they are at your
disposal. There is no hard and fast rule about when to use any mechanism in
the application programming space based upon "error severity" and such.
Certainly encountering "exceptional circumstances" does not necessarily
warrant using the C++ exception MECHANISMs. If you're trying to process
error in operators and constructors and such, it may be the easiest way and
the mechanisms are designed with that in mind (in addition to other
requirements such as cross-library error handling).

The name given to the C++ error handling mechanisms is probably unfortunate
in that it often confuses. If I'm pretty much on track with the above and
you accept it as so, than you realize that what mechanisms you use don't
really matter. Your taxonomy of errors and how to handle them and that you
do handle them is more important: how to handle user input errors (as
described above maybe), how to handle "exceptional circumstances"/"severe
errors" (msg box, log, notify, abort, maybe), etc. And your
taxonomy/categorization and handling will to some degree (probably to a
large degree) be application-specific.

Primarily, the key is to recognize that the C++ error processing mechanisms
were developed out of need to make the language work like they wanted it to
and the "exception" name given to those mechanisms shouldn't be over-thought
(made overly significant) when applying them. If the mechanisms will work
for you and you decide that that is the way to go, use them. If not, don't.
Substituting "C++ exceptions" with "the C++ error processing mechanism set"
may be helpful. Things like "belongs in the program flow" seem to be just
personal preference or one specific implementation. Searching for absolute
rules (the "right way") is futile I think, as there is more than one way to
skin a cat.

I think a discussion about categorization of errors and handling strategies
would be much more interesting than this one of which processing mechanisms
to use. That of course would belong in comp.programming and not in
comp.lang.c++ though. Another good discussion would be "Alternatives to
RAII/exceptions" or "RAII without exceptions".

John

 

[Gavin Deane]

GavinDeanewrote:
Actually, there is no need for a definition of "error" to make the rule

Use exceptions for error-handling only

work. If everybody obeys that rule, the use of an exception in the code will
communicate that the author considered the condition an error. Whether you
agree with that assesment or not is immaterial, the communication of intent
was nonetheless successful.

I can see your logic. I think I would have to reflect on it a while
before I could agree on the usefulness of communicating an intent when
you still leave outstanding the question of *why*. If I see an
exception in your code I know that you considered that situation to be
an "error" by your personal definition. But if I don't believe the
situation to be an error according to my personal definition, I'm not
sure that's helped me much in getting inside your head.

What about "error"
is it that gives you trouble? Could it be that you are reading too much
into the recommendation. The way I understand it (as far as communicating
intend goes) is:

Use exceptions to make clear that the handled condition is considered
an error.

As I say, without a common understanding of the definition of error,
there is nothing to explain *why* you think that condition is an error
and so, unless I happen to agree with you, I still haven't been able
to fully appreciate how you were thinking when you wrote that code.

There's another interesting point here if. If you use exceptions for
handling errors, that suggests that you are in a position to decide
which conditions will be handled by exceptions before you even start
to think about the structure of your program. By my approach I can't
do that, and I wouldn't want to.

I wouldn't want to because, as suggested elsethread, I don't want to
use an exception for a condition that is handled locally, even if I
believe that condition to be an error, and I don't want to rule out an
exception for a condition that is not handled locally, even if I
believe that condition not to be an error.

But even if I didn't care about those two, unlike you (I think) I am
not able to identify which conditions I will handle with exceptions
before designing the program structure because I first need to
identify the situations where I need to jump from one point in the
program to some other non-local point. Only after I have decided
(usually reluctantly) that I have that requirement will I consider
various ways to implement it. One of the options is an exception, but
it is only an implementation detail. I still want to communicate
intent, but the intent I want to communicate is "if condition x
arises, the flow of execution needs to jump away from here". If I feel
an exception is the best way of communicating that intent, that's what
I will use.

The question here is not so much whether this decision making process works
for you. It is more about whether recommending this decision making process
to others is wise. It could be that your personal understanding of what
is "cleanest" leads you to use exceptions only rarely. However, I wonder
whether others programmers understanding of what counts as clean is
sufficiently similar and will prevent them from using exceptions
dangerously often.

Well by my approach, exceptions are simply an implementation technique
available when the program structure calls for some spaghetti coding.
My own protection against over-use is that I understand the pitfalls
of jumping around the code and I try and minimise the need to do it.
If someone were following my approach and ended up using exceptions
often, that would not be a problem with my approach, it would be a
problem with their ability to design a program structure that didn't
involve jumping all over the place. Without that ability, even if you
banned exceptions, they would just use some other technique to
implement their spaghetti structure. The only solution I know is the
one you suggest - an increase in wisdom and experience and an
expectation that their approach to the same problem could change
significantly over time.

Gavin Deane

 

[JohnQ]

(The thread "Error Handling Idioms" prompted this post)

An attempt at common defintions:

fault: the cause of error.
error: a detected fault.
error handling: planned processing (perhaps via formal mechanisms) that
occurs upon fault detection.
error correction: returning a program (or system) back to an error-free
state.
failure: deviation from specified behavior (such as that which occurs when
an fault is not detected or an error not corrected or aborting).
C++ exception mechanisms, function return codes: 2 ways to facilitate
transfer of control to error handling code.

Note that by the above definitions, it is not always obvious if failure has
occurred. Case A: If a stray electron caused a memory bit to toggle and
caused the program to restart but then behave from there on as expected, I'd
say that is not failure. Case B: OTOH, if the program continually restarts,
I'd call that a failure.

Case A

Fault: stray electron. Error: noted memory corruption. Handling: solves
problem. Failure: Yes. Recovery: Yes.

Case B

Fault: dunno. Error: noted memory corruption. Handling: does not solve
problem. Failure: Yes. Recovery: No.

There are more important things (such as understanding of failure modes) to
worry about than which mechanism one uses to transfer control to an error
handler, IMO. C++ exceptions don't help with detection or correction ('try'
is not detection and 'catch' is not correction), the most important parts.
Also, I think that maybe trying to talk about errors in general rather than
specific errors or categories of errors may be futile.

John

 

[Alf P. Steinbach]

* JohnQ:

(The thread "Error Handling Idioms" prompted this post)

An attempt at common defintions:

fault: the cause of error.
error: a detected fault.

I'd switch those two definitions. ;-)

Anyway, I think the only sensible thing to do is to define what
terminology is used (locally), then use that terminology consistently.

 

[JohnQ]

* JohnQ:

I'd switch those two definitions. ;-)

How exactly? And why the sarcastic wink?

Anyway, I think the only sensible thing to do is to define what
terminology is used (locally), then use that terminology consistently.

What to do about this newsgroup locality and enabling discussion across
localities was the goal though.

John

 

[Grizlyk]

I posted a reply yesterday but it's not appeared yet. A delay that
long between posting and seeing the post is unusual through Google
Groups so I'll try again. Apologies for the double post if the first
one eventually appears.


I absolutely agree with the principle of code communicating intent.
However, for someone to say "exceptions are for error handling only"
is meaningless without a definition of "error".

"Error" is something o[[osite to "state". Error is violation of any
conventions, for example:

inline void zfill(char *const dst, const uint size)
{
if(!size)return;
//it is not error, because some arrays can have zero size

if(!dst)return;
//it is not error, because some arrays can be not allocated

memcpy(dst,0,size);
}

//do not post dst==0
inline void zfill2(char *const dst, const uint size)
{
if(!size)return;
if(!dst)safe_throw<err_zptr>("zfill2: dst");
//it is error, because we have required from client does not post NULL for
dst

memcpy(dst,0,size);
}

In some cases dividing into "error" or "state" is only your convention.

inline uint read(const char *const src)
{
if(!src)safe_throw<err_zptr>("read: src");
//it is error, because what data you will return from NULL?
}

Functions, returning only correct data is one of the source of exceptions,
because we just can not return any useful value while error.

Memory allocation, file opening and other resource management is other
source of exceptions, because we just can not continue if we have no memory
or can not work with file.

No one must use exception as "state switcher", due to low perfomans of
exception handling. Design pattern "state" can be used to implement complex
"state", when concrete methods of concrete interface of class depending from
concrete state.


--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

"In thi world of fairy tales rolls are liked olso"
/Gnume/

 

[Gavin Deane]

GavinDeanewrote:

I absolutely agree with the principle of code communicating intent.
However, for someone to say "exceptions are for error handling only"
is meaningless without a definition of "error".

"Error" is something o[[osite to "state". Error is violation of any
conventions, for example:

inline void zfill(char *const dst, const uint size)
{
if(!size)return;
//it is not error, because some arrays can have zero size

if(!dst)return;
//it is not error, because some arrays can be not allocated

memcpy(dst,0,size);
}

I would not regard those conditions as errors either, assuming (as I
think you do) that the function is intended to handle zero size arrays
and null pointers.

//do not post dst==0
inline void zfill2(char *const dst, const uint size)
{
if(!size)return;
if(!dst)safe_throw<err_zptr>("zfill2: dst");
//it is error, because we have required from client does not post NULL for
dst

memcpy(dst,0,size);
}

That's situation can only arise if there is a bug in the calling code.
I agree that you may want to do something in the function if the
precondition is violated. And you might decide that throwing an
exception is the thing you want to do. But as this situation can only
arise in an incorrect program, your example doesn't tell me anything
about the distinction between "failures" and "errors" in a correct
program.

Gavin

 

[Grizlyk]

I would not regard those conditions as errors either, assuming (as I
think you do) that the function is intended to handle zero size arrays
and null pointers.

There is no only one answer here. Whithout any additional condition it can
be either error, or not. The best choice to remove the undefined behavior is
strcit definition of the conditions of error. For pointers, the additional
precondition is often "to be non-zero", as the following example

That's situation can only arise if there is a bug in the calling code.

Yes. It is a bug in caller code, becasue we are assuming programmer can read
comment: "do not post dst==0". Unfortunatelly we can not detect the error at
compile time, so we need exception here, because we can not resolve the
error inside "zfill2" and can not quietly return, because all other correct
parts of code will expect correct zero filled buf.

I agree that you may want to do something in the function if the
precondition is violated. And you might decide that throwing an
exception is the thing you want to do.

We do not want, we are forced to return control into caller, because we do
not know what to do with the error and what part of program executed.

In reliable systems some failed parts of program can be easy stopped with
the help of exception and all other parts will continue to work, in spite of
all of them is sharing common libraries.

I think the best way to do separated reliable parts of program is process or
thread, but some small parts of program can be separated by C++ tools with
try/catch, without making tons of threads.

enum{ parts=10 };
void err_msg(const uint);

typedef void (*foo)();
extern foo part[parts];

extern char state[parts];

int main()
{
try{
memset(state,!0,parts);

for(;{
for(uint p=0; p<parts; ++p)
{
if(state[p])
try{ part[p](); }
catch(...){ state[p]=0; err_msg(p); }
}}
}
catch(...){err_msg(parts);}
}

By the way, the desire of C++ often to call "terminate" instead of possible
"throw" anything to up level (that can be catched with "catch(...)")
contradicts to reliable system requirements. The known C++ error points are:

- call "terminate" if exception has been thrown in function declared as
"throw()"
- call "terminate" on "double throw".

But as this situation can only
arise in an incorrect program, your example doesn't tell me anything
about the distinction between "failures" and "errors" in a correct
program.

This situation can only arise in a program, developed with independent parts
(in fact in each program). I do not speak about differences between
"failures" and "errors" only about differences between "state" and "errors".
Any "state switching" can be, but must not be resolved by exceptions.


--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

"In thi world of fairy tales rolls are liked olso"
/Gnume/