Error Handling
factfinder
I'm newish to ansi-C++, and I'm in the middle of a multi-file project on
MSVC++.
I would like to add some error handling / error reporting objects, but I
don't know where to start, as I've never done error handling on such a
massive scale.
Has anyone had to implement error-handling before? How did you do it? Is it
worth :
1) creating a list of #defined error codes?
2) can I circumvent try/catch/throw (i don't get on with them)?
3) If I had a generic error object, what would it do?!!
pls help, and thanks in advance... :o(
:o)
:o)
Victor Bazarov
> I'm newish to ansi-C++, and I'm in the middle of a multi-file project on
> MSVC++.
>
> I would like to add some error handling / error reporting objects, but I
> don't know where to start, as I've never done error handling on such a
> massive scale.
>
> Has anyone had to implement error-handling before?
You better believe it...
> How did you do it?
Exceptions, mostly.
> Is it
> worth :
>
> 1) creating a list of #defined error codes?
Sure, that's what MS does, anyway...
> 2) can I circumvent try/catch/throw (i don't get on with them)?
I wouldn't. You probably should get to know them better...
> 3) If I had a generic error object, what would it do?!!
Usually it's a descendant of std::exception and all it would do
is keep the error code and possibly translate it into humanly
readable form (a message). When your 'catch' clause is entered
you could output the error message (to the log, to the screen,
etc.) and also 'switch' based on the error code, for example.
Victor
--
Please remove capital A's from my address when replying by mail
Nithyanandham M
factfinder wrote:
Chapter 14, "Exception Handling" in "The C++ Programming Language-
Third Edition" has a discussion on this.
--
Nithyanand.
Siemens, Bangalore, India.
(Opinions expressed are my own and do not reflect the opinions of my employer,
SIEMENS)
factfinder
ok... I will learn to throw and catch (although if they're anything like my
ball skills I will be quite crap).
i am going off to find out about this 'exception object' and what it does
before I ask anymore lame questions. & thanks NM re the book reference
(Don't think I've the book to hand but thanks anyway :).
Bart Kowalski
news:uamdt4l...@corp.supernews.com...
Let's look at several error handling methods.
-------------------------------------
Method 1:
Returning an error value from a function. Using named constants to
denote the error.
Advantages:
- Every function has a known exit status that can be tested by the
caller.
- Named constants make the code easier to read.
- This approach is the simplest to implement and can be done by
any part of the program independently of other parts.
- An error can be ignored or postponed until it is convenient to
handle it.
Disadvantages:
- An error can be silently ignored, intentionally or by mistake.
- When a function doesn't handle the error it has to get the error
code and return it up the call-stack. In the worst case you end
up with many functions that have a lot of error checks that just
pass the error value to the caller. This means lots of code to
do simple things.
- Constructors and overloaded operators cannot return special
error codes.
- You have to reserve the return value for error checking and use
reference or pointer parameters for output from the function.
-------------------------------------
Method 2:
Calling a user-specified function when an error occurs.
Advantages:
- Constructors and overloaded operators can return an error.
- No need to reserve the return value for error checking.
- The error can be handled at the point where it occurs without
having to move up the call-stack.
Disadvantages:
- Slightly more complicated and less intuitive than return values.
- The function returns normally even though an error occurred,
requiring in some additional (sometimes quite ugly) hacks to
handle error conditions properly.
- Having many different callbacks for different error conditions
can quickly become a mess in larger programs that have many
different error types.
-------------------------------------
Method 3:
Setting a global or internal data member to indicate an error state.
Advantages:
- No need to reserve the return value for error checking.
- Constructors and overloaded operators cannot return an error,
but can still set the object to an invalid state to indicate
that an error occurred.
- An error can be ignored or postponed until it is convenient to
handle it.
Disadvantages:
- The user has to check the state of the object or the state of a
global variable before attempting some operations.
- An error may be detected in a completely different part of the
program than where it occurred, making error detection and
recovery difficult.
-------------------------------------
Method 4:
Throwing an exception.
Advantages:
- Constructors and overloaded operators can return an error.
- No need to reserve the return value for error checking.
- The error is handled where it makes sense to handle it, removing
all error-checking code in intervening functions.
- When an error occurs it cannot be ignored by mistake.
- Exceptions convey much more information than return values.
Disadvantages:
- The locations where errors can occur and the return paths are
much less predictable making good fault-tolerant code difficult
to write and hard to debug.
- Exceptions cannot be postponed. They have to be handled
immediately.
- To make effective use of exceptions they have to be used
throughout the entire program and have to be an integral part of
the design. It is impractical to confine exceptions to only part
of the program or to introduce them in later stages of
development.
The decision on which method to use is yours. Methods 1 and 2 are
mostly C idioms and not used frequently in modern C++ code. Method 3
is sometimes used, although in limited situations only. Method 4 is
the general C++ error handling mechanism, but it's very hard to really
get it right. Using exceptions is like juggling with razor-sharp
knives - it's very risky if you don't know what you're doing.
Consequently, a lot of not-so-modern C++ code uses simple return values
to avoid the complexities of exception handling, even though it might
not be the best approach.
Bart.
Cristian Zoicas
report the error to the user or
to another object.
In fact your question doesn't have an easy answer. Maybe you want to read some
error handling
strategies !!! If you need this please tell me. I can give you the address o a
document that i don't know where is right now.
For now, think about exceptions not as something that helps you *very very
much* to report the errors.
Think about exceptions as something that cannot be ignored. An exception or is
catched or you program
will crash.
This is the oposite with the old error handling when a function return 0 for
example to signal an error. Even if the function return 0, the program will
contine to run. It is not *mandatory* to test if the function returned 0 but
is recomended.
Cristi Zoicas
Alexander Terekhov
Bart Kowalski wrote:
[...]
> Method 2:
>
> Calling a user-specified function when an error occurs.
>
> Advantages:
>
> - Constructors and overloaded operators can return an error.
What do you mean?
[...]
> Method 3:
>
> Setting a global or internal data member to indicate an error state.
>
> Advantages:
NONE (unless with "Method 3" you actually mean the "basic"
exception{error}-safety guarantee but using return/status
codes for "manual/always" unwinding - another rather brain-
damaged thing, to begin with).
[...]
> Method 4:
>
> Throwing an exception.
[...]
> Disadvantages:
>
> - The locations where errors can occur and the return paths are
> much less predictable making good fault-tolerant code difficult
> to write and hard to debug.
NONSENSE.
regards,
alexander.
Alexander Terekhov
factfinder wrote:
>
> Hi,
>
> I'm newish to ansi-C++, and I'm in the middle of a multi-file project on
> MSVC++.
>
> I would like to add some error handling / error reporting objects, but I
> don't know where to start, as I've never done error handling on such a
> massive scale.
>
> Has anyone had to implement error-handling before? How did you do it?
Read this: ("class nothrow" == std::nothrow_t)
http://www.bleading-edge.com/Publications/C++Report/v9603/Article2a.htm
http://www.bleading-edge.com/Publications/C++Report/v9605/Column1.htm
http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
http://www.boost.org/more/generic_exception_safety.html
http://www.gotw.ca
Also, you better forget about "catch(...)/ignore" and/or
"re-throw concept" in general, right from the beginning...
regards,
alexander.
Bart Kowalski
news:3CAC2CA2...@web.de...
<snip troll>
PLONK!
Bart.
Alexander Terekhov
Bart, could you please clarify for me what exactly
did you want to communicate to me (or perhaps to others)
with this rather brief reply? And, BTW, with respect to
whom?)? FYI (and I've somehow lost the links, sorry):
-----
>PLONK Person Leaving Our Newsgroup (Killfiltered)
>PLONK Person with Little Or No Knowledge
>PLONK Put Lamer On Kill Filter (USENET)
PLONK Pashtuns Love Our Noggin Klonkers!
PLONK Pent-up Lust Often Nudges Knockers!
PLONK Police Lambast Our Nemesis -- Kent!
PLONK Paminifarm Lingers On -- Never Kaput!
-----
Perhaps one of the most interesting and colorful words
in the English language today is the word "*PLONK*". It
is the one magical word which, just by its sound, can
describe pain, pleasure, love, and hate. In language,
"*PLONK*" falls into many grammatical categories. It can
be used as a verb, both transitive (John *PLONK*ed Mary)
and intransitive (Mary was *PLONK*ed by John).
It can be an action verb (John really gives a *PLONK*),
a passive verb (Mary really doesn't give a *PLONK*), an
adverb (Mary is *PLONK*ing interested in john), or as a
noun (Mary is a terrific *PLONK*). It can also be used
as an adjective (Mary is *PLONK*ing beautiful) or an
interjection (*PLONK*! I'm late for my date with Mary).
It can even be used as a conjunction (Mary is easy,
*PLONK* she's also stupid). As you can see, there are
very few words with the overall versatility of the word
"*PLONK*". Aside from its sexual connotations, this
incredible word can be used to describe many situations:
1. Greetings--- "How the *PLONK* are ya?"
2. Fraud--- "I got *PLONK*ed by the car dealer."
3. Resignation--- "Oh, *PLONK* it!"
4. Trouble--- "I guess I'm *PLONK*ed now."
5. Aggression--- "*PLONK* YOU!"
6. Disgust--- "*PLONK* me."
7. Confusion--- "What the *PLONK*.......?"
8. Difficulty--- "I don't understand this *PLONK*ing business!"
9. Despair--- "*PLONK*ed again..."
10. Pleasure--- "I *PLONK*ing couldn't be happier."
11. Displeasure--- "What the *PLONK* is going on here?"
12. Lost--- "Where the *PLONK* are we."
13. Disbelief--- "UN*PLONK*INGBELIEVABLE!"
14. Retaliation--- "Up your *PLONK*ing ass!"
15. Denial--- "I didn't *PLONK*ing do it."
16. Perplexity--- "I know *PLONK* all about it."
17. Apathy--- "Who really gives a *PLONK*, anyhow?"
18. Suspicion--- "Who the *PLONK* are you?"
19. Panic--- "Let's get the *PLONK* out of here."
20. Directions--- "*PLONK* off."
21. Disbelief--- "How the *PLONK* did you do that?"
It can be used in an anatomical description- "He's a *PLONK*ing
asshole".
It can be used to tell time- "It's five *PLONK*ing thirty".
It can be used in business- "How did I wind up with this *PLONK*ing
job?"
It can be maternal- "Mother*PLONK*er".
It can be political- "*PLONK* Dan Quayle!"
It has also been used by many notable people throughout history:
"What the *PLONK* was that?"
--- "Mayor of Hiroshima
"Where did all these *PLONK*ing Indians come from?"--- General Custer
"Where the *PLONK* is all this water coming from?"
--- Captain of the Titanic
"Thats not a real *PLONK*ing gun."
--- John Lennon
"Who's gonna *PLONK*ing find out?"
--- Richard Nixon
"Heads are going to *PLONK*ing roll."
--- Anne Boleyn
"Let the *PLONK*ing woman drive."
--- Commander of Space Shuttle Challenger
"What *PLONK*ing map?"
--- Mark Thatcher
"Any *PLONK*ing idiot could understand that."
--- Albert Einstein
"It does so *PLONK*ing look like her!"
--- Picasso
"How the *PLONK* did you work that out?"
--- Pythagoras
"You want what on the *PLONK*ing ceiling?"
--- Michaelangelo
"*PLONK* a duck."
--- Walt Disney
"Why?- Because its *PLONK*ing there!"
--- Edmund Hilary
"I don't suppose its gonna *PLONK*ing rain?"
--- Joan of Arc
"Scattered *PLONK*ing showers my ass."
--- Noah
"I need this parade like I need a *PLONK*ing hole in my head."
--- John F. Kennedy
----
regards,
alexander.
Edwin Robert Tisdale
> I would like to add some error handling/reporting objects
> but I don't know where to start
> as I've never done error handling on such a massive scale.
>
> Has anyone had to implement error-handling before?
> How did you do it?
> Is it worth:
>
> 1) creating a list of #defined error codes?
> 2) can I circumvent try/catch/throw (I don't get on with them)?
> 3) If I had a generic error object, what would it do?
It is a good idea to define and use error codes
if you have more than a few different kinds of errors
especially if you need to write a program
that automatically parses the error stream
and routes error messages to the people responsible for them.
The C++ exception handling mechanism
should always be your method of last resort.
First, you should try to handle errors in the scope
of the function where they are first detected.
If you can't handle the error in the function scope
where it is detected, you should ask yourself,
"Why wasn't this error detected
before the function was called?"
The realization that you can't handle an error
in the local function scope should be a yellow flag
that alerts you to possible design flaws.
Ideally, all errors would be detected and handled
in the main program. For example,
you should try to open, read and validate inputs
or write outputs then close the file in the main program.
But, more generally, it isn't practical or even possible
to detect input errors at the highest level
so you are obliged to pass them down to functions
which might not be able to completely handle
all of the errors that it detects.
You can return an error code by value
Error_code f(X& x);
or as a argument passed by reference
void g(X& x, Error_code& error);
to a void function but it doesn't make any sense
to implement a function
Y h(const X& x, Error_code& error);
that returns anything besides an error code by value
because you must test the error code
before you use the return value.
If you want to use function
Y h(const X& x);
in an expression, it must throw an exception
for any detected errors that it cannot handle.
NotFound
> in the main program. For example,
> you should try to open, read and validate inputs
> or write outputs then close the file in the main program.
What? You must first read the file to ensure that is valid, then pass it
to a function that read it again?
> But, more generally, it isn't practical or even possible
> to detect input errors at the highest level
> so you are obliged to pass them down to functions
Ah, your 'ideally' is some sort of platonism, then?
And we must avoid the excepctions because they are not similar to this
ideal world?
Regards.
Mike Hewson
<snip twaddle>
--
No Cheers
--
Hewson::Mike
"I have made this letter longer than usual because I lack
the time to make it shorter."
- Blaise Pascal
FAQ's
alt.comp.lang.learn.c-c++ : http://snurse-l.org/acllc-c++/faq
comp.lang.c++ : http://www.parashift.com/c++-faq-lite/