need argument for try catch blocks

[Öö Tiib]

  What is an error?

  What is noise? (in the above context)

  What makes that noise be an error?

For example you are measuring something with some sensor say once in
every 200 nanoseconds. Sensor is usually accurate but frequently (in
average once in 5 milliseconds) it gives some "peaks" out of nothing.
You should not throw on one despite they are wrong and you should not
use them in calculations because they are wrong.

  things of which it is not known whether they are errors (...) ?

Yes. Can you explain what you don't understand? There are always dim
areas in every documentation so it is not described what should you do
in certain situation. Looking at documented exceptions you find none
that match with situation. You can fire bug report about documentation
but often you have to implement something right now. Better you
implement it to handle it gracefully, otherwise you will later likely
have to rewrite it. You should avoid inventing some undocumented
exceptions or throwing std::runtime_errors on unclear case.

 

[Stefan Ram]

Yes. Can you explain what you don't understand?

This question is based on an inapplicable assumption.

 

[Öö Tiib]

  This question is based on an inapplicable assumption.

The sentence "things of which it is not known whether they are errors
(...) ?" has question mark at end but does not form a question so i
did not get what you were asking.

If it is just because of my English then i have to excuse that it is
4th language i leaned to speak more or less. Even native English
speakers do not understand each other often enough so please don't
make it any harder than it already is.

 

[MikeP]

That sounds like the usual "silver bullet" and "trigger happy"
misconception of *ALWAYS* and *NEVER*. Have you written some software
or are you just trolling?

First, the errors that happen often, (for example a noise from some
communication device) should be handled without exceptions from
performance point of view.

Non sequitor. If it is not an error, then it is off-topic in regards to
my post.

Second, things that are unclear if they are errors should be always
handled without exceptions. Why std::set<>::insert() returns
pair<bool,iterator> (same with std::map)? Because on lot of cases it
is only known to caller if inserting to set or to map something that
was already there is error or not.

Non-sequitor. Only error management was considered in my post, not the
fine-grained elements which are used to create application objects.

Third, when the function should clean, erase, release or close
something but fails. These functions may be are called from
destructors and the little problems and failures of a janitor do not
matter on lot of cases. Therefore these should work without throwing
exceptions. Throwing from such is invasive, bad design and the true
weakest link from robustness point of view.

Weak: ancillary information dances around in the general area but makes
no case for or against key points.

These were only first few cases that popped into mind, but they feel
lot enough to show your ideology of "ALL errors" as quite
questionable.

Oh, so when do you want to start talking about errors? Tomorrow?

Keyphrase: Eye on the ball.

 

[Öö Tiib]

Non sequitor. If it is not an error, then it is off-topic in regards to
my post.

What is "an error" then? For me it is something that deviates from
correct.

Non-sequitor. Only error management was considered in my post, not the
fine-grained elements which are used to create application objects.

What is "an error" then? For me it is something that deviates from
correct.

Weak: ancillary information dances around in the general area but makes
no case for or against key points.

Code that has a chance to throw from destructor is opposite to robust.
Code that lures maintainers to write destructors that have chance to
throw is hard to maintain. So what are your "key points"?

Oh, so when do you want to start talking about errors? Tomorrow?

It is impossible to discuss that mythical term "error" of yours that
feels to exist somewhere outside of my experience. For me there is
thin layer of correct things. Everything deviating from that is an
error (or yet not defined as correct).

I throw exceptions only from non-cleanup functions on errors for what
i have documentation that i may throw on these. That means my code
usually has quite lot of throws written into it. It actually throws
very rarely. When i test the program and see that it throws a lot of
exceptions in some situation then i rearrange the things so it does
not throw in that situation or throws less. Your "PORCs" are fine and
robust tool for arranging that.

 

[MikeP]

What is "an error" then? For me it is something that deviates from
correct.

No, what you are describing above is a "failure": a deviation from
specifications. "error" precedes that and that is when there is still
time to do something about the error. An error is the part of the system
state that may likely lead to failure. An error is the thing you notice
(detect) that is awry. (This is really textbook-level stuff, but it's fun
to take a break from the deep-thought issues and improve language
(English) skills too sometimes by stating the obvious, not to mention
that common glossary is required for effective communication to happen).

 

[MikeP]

No, what you are describing above is a "failure": a deviation from
specifications. "error" precedes that and that is when there is still
time to do something about the error. An error is the part of the
system state that may likely lead to failure. An error is the thing
you notice (detect) that is awry. (This is really textbook-level
stuff, but it's fun to take a break from the deep-thought issues and
improve language (English) skills too sometimes by stating the
obvious, not to mention that common glossary is required for
effective communication to happen).

"obvious" was a poorly chosen word. "well-defined" is what I was after.

 

[Öö Tiib]

"obvious" was a poorly chosen word. "well-defined" is what I was after.

Huh? "Thing being awry" is better definition for "Error" since it
differs somehow from "Something deviating from correct"? What is the
name and author of the textbook of yours? For me throwing exceptions
is indeed one way to fail and to signal about the failure. Are you
trying to humor me?

 

[Joshua Maurice]

No, what you are describing above is a  "failure": a deviation from
specifications. "error" precedes that and that is when there is still
time to do something about the error. An error is the part of the system
state that may likely lead to failure. An error is the thing you notice
(detect) that is awry. (This is really textbook-level stuff, but it's fun
to take a break from the deep-thought issues and improve language
(English) skills too sometimes by stating the obvious, not to mention
that common glossary is required for effective communication to happen).

One should not use exceptions for all errors. Consider an expression
evaluator which operates on many rows. Suppose it detects a division
by zero before doing the actual division. Suppose the specification of
this expression evaluator is to return a specific error flag for all
such rows. It would be prohibitively expensive to use exceptions to
deal with such errors in the middle of the expression evaluator
Instead, error return codes should be used in the expression
evaluator.

 

[MikeP]

Huh? "Thing being awry" is better definition for "Error" since it
differs somehow from "Something deviating from correct"? What is the
name and author of the textbook of yours? For me throwing exceptions
is indeed one way to fail and to signal about the failure. Are you
trying to humor me?

You can't just pick out a couple of words and throw away the entire
context to suit your agenda. If "awry" was too strong, it should be clear
from all of the surrounding text, which you conveniently "ignored" in
attempt to make some kind of "point" or stand, the meaning. Reread what I
wrote and take it ALL in this time instead of searching for a way to
exploit minutiae in attempt to invalidate the information.

I was saying this stuff is fundamental textbook material. Perhaps you
should get one and bone up on the material that way because you are not
going to believe me no matter how plainly I try to state it, which I
tried to do above. All I have for you on the matter I already wrote
above. I'm not your personal tutor. I did you a service by giving you a
jumping off point to do web searches or to find books to read. If you
want the knowledge, you will go seek out the information. I'm not going
to spoon-feed it to you though.

 

[MikeP]

One should not use exceptions for all errors. Consider an expression
evaluator which operates on many rows. Suppose it detects a division
by zero before doing the actual division. Suppose the specification of
this expression evaluator is to return a specific error flag for all
such rows. It would be prohibitively expensive to use exceptions to
deal with such errors in the middle of the expression evaluator
Instead, error return codes should be used in the expression
evaluator.

Let's assume (perhaps for just a moment) that the above really does
describe an "error" scenario. Well then, that would be a very much
milder suggestion than "only use exceptions when the immediate caller
will not be handling the error". "ALL" may be indeed too encompassing
(though not yet clearly so), but then there are "always" (see, I put
quotes arroun the extreme word this time) exceptions to the rule. "ALL"
is still much closer to best practice than "only when the immediate
calller will not...", which seems to be a WORST practice, or worse,
simply incorrect usage of the facilities. Any further discussion should
focus on "use exception mechanisms for error handling ALL the time" vs.
"only use exception mechanisms when the immediate caller will not be
handling the error ("exception" if you prefer that terminology)".

 

[MikeP]

You can't just pick out a couple of words and throw away the entire
context to suit your agenda. If "awry" was too strong, it should be
clear from all of the surrounding text, which you conveniently
"ignored" in attempt to make some kind of "point" or stand, the
meaning. Reread what I wrote and take it ALL in this time instead of
searching for a way to exploit minutiae in attempt to invalidate the
information.
I was saying this stuff is fundamental textbook material. Perhaps you
should get one and bone up on the material that way because you are
not going to believe me no matter how plainly I try to state it,
which I tried to do above. All I have for you on the matter I already
wrote above. I'm not your personal tutor. I did you a service by
giving you a jumping off point to do web searches or to find books to
read. If you want the knowledge, you will go seek out the
information. I'm not going to spoon-feed it to you though.

And I get cranky at the end of the day, so it's not a good time to try my
(lack of) patience. LOL.

 

[Joshua Maurice]

Let's assume (perhaps for just a moment) that the above really does
describe an "error" scenario. Well then, that  would be a very much
milder suggestion than "only use exceptions when the immediate caller
will not be handling the error". "ALL" may be indeed too encompassing
(though not yet clearly so), but then there are "always" (see, I put
quotes arroun the extreme word this time) exceptions to the rule. "ALL"
is still much closer to best practice than "only when the immediate
calller will not...", which seems to be a WORST practice, or worse,
simply incorrect usage of the facilities. Any further discussion should
focus on "use exception mechanisms for error handling ALL the time" vs.
"only use exception mechanisms when the immediate caller will not be
handling the error ("exception" if you prefer that terminology)".

In my example of an expression evaluator, it's quite possible that the
immediate caller will not be handling it. (We can always discuss
whether it makes sense to write an expression evaluator so that each
operator in the expression gets a C function call activation, but
let's ignore that for now.)

In that context, the immediate caller will not be handling the
problem. Instead, it will propagate up an error code until eventually
the initial caller of the expression evaluator will see that the row
is an "error row". It will increment a count of number of error rows,
and proceed to the next row. Btw, this is basically one aspect of my
company's product. The technical term in our user docs is literally
"error row". It would be ridiculously bad for performance for some of
our customer use cases if we had implemented this error with
exceptions.

The far better piece of advance is: If it's a /fatal/ error, that is
if it is some thing which will result in the termination of the
current "job" or "sub-job", or if it demands user input to resolve,
then exceptions are a good fit. The basic idea is that in such "fatal"
cases, performance is no longer a criterion.

"Out of memory" is a great example. There's not much a program can do
with an "out of memory" error in most cases besides to kill the job
(or some sub-job of the job), and report it to the user, try again, or
wait until other jobs are finished and try again. (And that's being
idealistic. I expect a lot of programs don't handle "out of memory"
"gracefully" at all, instead choosing to abort.)

 

[MikeP]

In my example of an expression evaluator, it's quite possible that the
immediate caller will not be handling it.

I haven't thought about it enough to decide whether you have an error
scenario or not, so I can't comment on the rest of your post unless I
agree that it is such, and of course I certainly won't assume such. It
may be just a normal control flow sceario. TBD. Or not: I was going to
say I'd think about it tomorrow morning, but actually, I really can't
take the time to familiarize with your use case.

[snipped poster's use case]

The far better piece of advance is: If it's a /fatal/ error, that is
if it is some thing which will result in the termination of the
current "job" or "sub-job", or if it demands user input to resolve,
then exceptions are a good fit. The basic idea is that in such "fatal"
cases, performance is no longer a criterion.

It may be just a classification difference: you putting some things which
are in the "normal control flow" arena into the "error" arena.

"Out of memory" is a great example. There's not much a program can do
with an "out of memory" error in most cases besides to kill the job
(or some sub-job of the job), and report it to the user, try again, or
wait until other jobs are finished and try again.

Let's see, you in one breath said "not much one can do" and gave 3
examples of what one can do?

 

[Stefan Ram]

describe an "error" scenario. Well then, that would be a very much

What is an error?

So far, no one has given a general answer.

Let me try to give at least one example.

»Computer giant IBM thoroughly investigated the problem
in the mid 90s, testing nearly 1,000 memory devices at
sea level, in mountains and in caves. They showed that
at higher altitude, more soft errors occurred, while in
the caves there were nearly none. That proved cosmic
rays were to blame.«

http://www.newscientist.com/blog/technology/2008/03/do-we-need-cosmic-ray-alerts-for.html

When a cosmic ray flips a bit, that I'd call an error.

An example for detection:

int const i = 0;
if( i )env->log( "Oops! Try this code at a lower computer altitude." );

 

[Stefan Ram]

int const i = 0;
if( i )env->log( "Oops! Try this code at a lower computer altitude." );

Adding a "volatile" here and there, won't hurt, too.

 

[MikeP]

What is an error?

So far, no one has given a general answer.

Yes I have:

No, what you are describing above is a "failure": a deviation from
specifications. "error" precedes that and that is when there is still
time to do something about the error. An error is the part of the
system state that may likely lead to failure. An error is the thing
you notice (detect) that is awry.

Save for the choice of the word 'awry', I think that's right on target
(and that is in an ancillary sentence anyway). Extracting the meat from
the above gives:

An error is the part of the system state that may likely lead to
failure.

That definition suits me just fine. I welcome other stabs at it, though I
probably don't have a need to adopt anything different after so long, for
my own purposes. I didn't come up with the above definition, I learned it
from somewhere and adopted it as the one I prefer best. I'll bibliograph
it if I find the source again.

 

[MikeP]

Yes I have:


Save for the choice of the word 'awry', I think that's right on target
(and that is in an ancillary sentence anyway). Extracting the meat
from the above gives:

An error is the part of the system state that may likely lead to
failure.

"may likely" should probably be replaced with "can possibly". Picking
nits now.

 

[Stefan Ram]

An error is the part of the system state that may likely lead to
failure.

»may likely« is a little bit too vague for my taste.

Possibly, an example, would help?

When an error is a part of the system (run-time) state,
there cannot be errors in the source code, because the
source code is not part of the system state?

 

[MikeP]

»may likely« is a little bit too vague for my taste.

I don't have a problem with any vaguery, I have a problem with its
correctness. I suggested in a follow-up post to my own post that "can
possibly" might be better than "may likely".

Possibly, an example, would help?

Sure, OK. Consider that not every error, though still an error, will not
necessarily lead to failure. For example:

A top fuel funny car engine may eject its magneto (OK, back in the day
when they only had one) through the carbon fiber body (OK, maybe
fiberglass back then) into the high heavens (ah, night time drag
racing... quite a spectacle... and everyone knows that heaven is absent
during the day) at the starting line upon car launch because the retainer
used was made from forged aluminum alloy instead of titanium, but the car
may still reach the finish line with nary a dent in it's average elapsed
time on the quarter mile because the highly volatile nitro fuel ignites
in the combustion chambers of the engine even without the aid of the
ignition system because the engine behaved like a compression-ignition
engine (think diesel) over the 1/4 mile trek.

System: Top fuel funny car.
Error: Missing magneto!
Failure: None.

(The specification (specified behavior) says the car must reach the
finish line under 4.5 seconds (OK, 7 seconds back then), but nothing
about having to arrive with all components it started with, so the
magneto ejection cannot be taken as a failure in and of itself).

System: Keith Black Hemi funny car engine.
Error: Aluminum instead of titanium magneto retainer.
Failure: Ejected magneto.

When an error is a part of the system (run-time) state,
there cannot be errors in the source code, because the
source code is not part of the system state?

All source code DEFECTS are erradicated during debugging and testing.
(LOL!). There is no way to deal with software defects ("bugs") other than
to fix them* so it behooves to have a very, very comprehensive way to
flush-out all the defects. Exceptions can't help with bugs, other than to
help weed them out during development/testing (if one uses exceptions
thusly) along with assertions. So, it is easy to see that one cannot hope
for much given a defective program to beging with: ANYTHING can happen!

*Of course that is not true absolutely, but within the context of a
single unmonitored program it is.