Exceptions - do you use them?
Heiko Gottschling
what's your general opinion about exceptions? Do you use them, and if
you don't, why not?
It seems there are two basic objections against using exceptions:
1. Making a program _really_ safe may require great efforts and may be
non-trivial (see
http://www.awlonline.com/cseng/meyerscddemo/DEMO/MAGAZINE/CA_FRAME.HTM )
2. Performance penalty. Any information on how exceptions slow down your
program?
thx
Heiko
Marc1917
"Heiko Gottschling" <nos...@ottomalotto.de> wrote in message
news:3C5E67BC...@ottomalotto.de...
> Hi,
>
> what's your general opinion about exceptions? Do you use them, and if
> you don't, why not?
>
Just use them around external library calls, my own program code
crashes where it crashes, and one can see which code line. The exception
call let it jump to the end of the try catch block and then one does
not know where the error is.
Marc1916
Jon Bills
news:a3lroa$194soj$1...@ID-123884.news.dfncis.de...
>
> "Heiko Gottschling" <nos...@ottomalotto.de> wrote in message
> news:3C5E67BC...@ottomalotto.de...
> > Hi,
> >
> > what's your general opinion about exceptions? Do you use them, and if
> > you don't, why not?
> >
>
> Just use them around external library calls, my own program code
> crashes where it crashes, and one can see which code line.
You should not be knowingly allowing your code to crash at all,
regardless of error handling mechanism. A crash is often the result
of undefined behaviour, often propagated due to an unexpected value
computed somewhere. Allowing this to cause a crash is not a good
strategy, since disgraceful degradation of the application is only one
possible outcome.
> The exception
> call let it jump to the end of the try catch block and then one does
> not know where the error is.
Exceptions are one means of achieving graceful degradation in the face
of error. The point is not just to provide information to the developer,
but also to behave sensibly for the user.
> Marc1916
Jon.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Marc1917
"Jon Bills" <jon_...@hotmail.com> wrote in message
news:656414ecea7239a774d...@mygate.mailgate.org...
> "Marc1917" <beepbe...@hotmail.com> wrote in message
> news:a3lroa$194soj$1...@ID-123884.news.dfncis.de...
>
> >
> > "Heiko Gottschling" <nos...@ottomalotto.de> wrote in message
> > news:3C5E67BC...@ottomalotto.de...
> > > Hi,
> > >
> > > what's your general opinion about exceptions? Do you use them, and if
> > > you don't, why not?
> > >
> >
> > Just use them around external library calls, my own program code
> > crashes where it crashes, and one can see which code line.
>
> You should not be knowingly allowing your code to crash at all,
> regardless of error handling mechanism.
I do not code and think, let the code crash here! I am talking
about unexpected program errors and consequences.
>A crash is often the result
> of undefined behaviour, often propagated due to an unexpected value
> computed somewhere. Allowing this to cause a crash is not a good
> strategy, since disgraceful degradation of the application is only one
> possible outcome.
>
What do you mean, I should write perfect code? I can't I am sorry.
>
> Exceptions are one means of achieving graceful degradation in the face
> of error. The point is not just to provide information to the developer,
> but also to behave sensibly for the user.
>
I think if the exeption result unexpected behaviour I can not say much more
then "Houston we have a mayor malfunction", which only masks the error,
and only looks a bit better from the outside.
@wanadoo.fr dwarfpower
"Jon Bills" <jon_...@hotmail.com> a écrit dans le message de news:
656414ecea7239a774d...@mygate.mailgate.org...
> "Marc1917" <beepbe...@hotmail.com> wrote in message
> news:a3lroa$194soj$1...@ID-123884.news.dfncis.de...
>
> >
> > "Heiko Gottschling" <nos...@ottomalotto.de> wrote in message
> > news:3C5E67BC...@ottomalotto.de...
> > > Hi,
> > >
> > > what's your general opinion about exceptions? Do you use them, and if
> > > you don't, why not?
> > >
> >
> > Just use them around external library calls, my own program code
> > crashes where it crashes, and one can see which code line.
>
> You should not be knowingly allowing your code to crash at all,
> regardless of error handling mechanism. A crash is often the result
> of undefined behaviour, often propagated due to an unexpected value
> computed somewhere. Allowing this to cause a crash is not a good
> strategy, since disgraceful degradation of the application is only one
> possible outcome.
>
by errors i mean a non rspect of the condition of use of a given piece of
software
resource non accessible, protocol not respected.. etc but not a bug
protection facility
you can even use exception to replace the old return code of function,
using the return statement to return usefull data instead of teh diagnostic
so , IMHO, exception should not be used to avoid an unpredicted crash
Jon Bills
>
[snip]
> > You should not be knowingly allowing your code to crash at all,
> > regardless of error handling mechanism.
>
> I do not code and think, let the code crash here!
That's what you seemed to be implying.
> I am talking about unexpected program errors and consequences.
>
> > A crash is often the result
> > of undefined behaviour, often propagated due to an unexpected value
> > computed somewhere. Allowing this to cause a crash is not a good
> > strategy, since disgraceful degradation of the application is only one
> > possible outcome.
> >
>
> What do you mean, I should write perfect code? I can't I am sorry.
No, I'm saying you should code defensively. i.e. you don't let
unexpected values propagate, you do check pre and post conditions, etc.
> > Exceptions are one means of achieving graceful degradation in the face
> > of error. The point is not just to provide information to the developer,
> > but also to behave sensibly for the user.
> >
>
> I think if the exeption result unexpected behaviour I can not say much more
> then "Houston we have a mayor malfunction", which only masks the error,
> and only looks a bit better from the outside.
Exceptions exist to handle unexpected problems.
@wanadoo.fr dwarfpower
> Exceptions exist to handle unexpected problems.
>
> Jon.
>
Jon Bills
news:a3lt48$cbj$1...@wanadoo.fr...
[snip]
> > You should not be knowingly allowing your code to crash at all,
> > regardless of error handling mechanism. A crash is often the result
> > of undefined behaviour, often propagated due to an unexpected value
> > computed somewhere. Allowing this to cause a crash is not a good
> > strategy, since disgraceful degradation of the application is only one
> > possible outcome.
> >
> exception is a mean for diagnostic, a way to deal with errors not crashes
Handling errors helps prevent crashes. I don't see a real distinction
here.
> by errors i mean a non rspect of the condition of use of a given piece of
> software
> resource non accessible, protocol not respected.. etc but not a bug
> protection facility
Sorry, that's just noise.
> you can even use exception to replace the old return code of function,
> using the return statement to return usefull data instead of teh diagnostic
Yes, and...?
> so , IMHO, exception should not be used to avoid an unpredicted crash
Are you saying that crashes cannot be avoided? I'd agree to an extent,
but there is something that can be done in your own code.
Marc1917
"dwarfpower" <dwarf.power @ wanadoo.fr> wrote in message
news:a3ltn6$bgs$1...@wanadoo.fr...
> >
> > Exceptions exist to handle unexpected problems.
> >
> > Jon.
> >
> No they exists to handle expected ones
>
Agreed, the unexpected ones need to crash, better crash good and repair then
a bandaid exception handling that covers up the error!
Marc1917
> > >
> > exception is a mean for diagnostic, a way to deal with errors not
crashes
>
> Handling errors helps prevent crashes. I don't see a real distinction
> here.
>
And by this you let the error exist in the code, at the end their are so
many patches
and bandaids in your code it is difficult to change it: since then you might
experience
the error that was covered up by the execption handling.
Jon Bills
news:a3ltn6$bgs$1...@wanadoo.fr...
> >
> > Exceptions exist to handle unexpected problems.
> >
> > Jon.
> >
> No they exists to handle expected ones
The above 2 statements are *not* mutually exclusive.
Jon Bills
> > > Exceptions exist to handle unexpected problems.
> > >
> > > Jon.
> > >
> > No they exists to handle expected ones
> >
>
> Agreed, the unexpected ones need to crash, better crash good and repair then
> a bandaid exception handling that covers up the error!
You need to think carefully about where crashes in your own code
originate. A crash is not a desired outcome of unexpected input!
If you don't hand the OS junk, then you don't give the OS cause to
crash.
@wanadoo.fr dwarfpower
>
> Are you saying that crashes cannot be avoided? I'd agree to an extent,
> but there is something that can be done in your own code.
>
> Jon.
No i just say that crashes should not be artificially avoided
if after an error occured you can recover from the exception then
it was a predictable error, so it is not a bug
if you catch an un predicted exeception with a generic catch statement how
can you treat the exception ?
without knowing what hapenned ( the case if it is an unpredicted one ) how
can you be sure you can go on with the program
the integrity of the software is perhapslost without you knowing it.. better
a crash in that case
dwarfpower
@wanadoo.fr dwarfpower
> > > >
> > > > Jon.
> > > >
> > > No they exists to handle expected ones
> > >
> >
> > Agreed, the unexpected ones need to crash, better crash good and repair
then
> > a bandaid exception handling that covers up the error!
>
> You need to think carefully about where crashes in your own code
> originate. A crash is not a desired outcome of unexpected input!
> If you don't hand the OS junk, then you don't give the OS cause to
> crash.
true, you have to test the input are accceptable and if not throw a
documented thsu expected exception
just as execption mechanisme should not be used to hide bugs, crashes should
not be used as a dignostic
for unpredicted behavior
Jon Bills
> > > so , IMHO, exception should not be used to avoid an unpredicted crash
> >
> > Are you saying that crashes cannot be avoided? I'd agree to an extent,
> > but there is something that can be done in your own code.
> >
> > Jon.
>
> No i just say that crashes should not be artificially avoided
> if after an error occured you can recover from the exception then
> it was a predictable error, so it is not a bug
I never said you can always recover from an error. That doesn't mean
the only course of action is for the application to crash.
> if you catch an un predicted exeception with a generic catch statement how
> can you treat the exception ?
> without knowing what hapenned ( the case if it is an unpredicted one ) how
> can you be sure you can go on with the program
> the integrity of the software is perhapslost without you knowing it.. better
> a crash in that case
I'll let you into a little secret... you are allowed to have your
program terminate itself with an error message. Amazing, huh?
> dwarfpower
@wanadoo.fr dwarfpower
> "dwarfpower" <"dwarfpower"> wrote in message
> news:a3ltn6$bgs$1...@wanadoo.fr...
>
> > >
> > > Exceptions exist to handle unexpected problems.
> > >
> > > Jon.
> > >
> > No they exists to handle expected ones
>
> The above 2 statements are *not* mutually exclusive.
>
>
unexpected exception
there are errors and bugs. an error accurs when a piece of software is not
used accordingly to its documented us
a bug occurs when an unpredicted result from acceptable input
in order to deal with error you catch documented exception, wheras in order
to patch a bug with axception mechanisme you catch generic exception and do
not treat them, since you do not know the cause of it
Jon Bills
[snip]
> true, you have to test the input are accceptable and if not throw a
> documented thsu expected exception
> just as execption mechanisme should not be used to hide bugs, crashes should
> not be used as a dignostic
> for unpredicted behavior
Do you ever stop to read your posts before hitting the 'send' button?
@wanadoo.fr dwarfpower
reason"
or
"Error: close your application"
if you don't know how to deal with something, just don't deal with it
dwarfpower
Jon Bills
[snip]
> yes they are not but that does not mean it is good practive to catch
> unexpected exception
>
> there are errors and bugs. an error accurs when a piece of software is not
> used accordingly to its documented us
> a bug occurs when an unpredicted result from acceptable input
>
> in order to deal with error you catch documented exception, wheras in order
> to patch a bug with axception mechanisme you catch generic exception and do
> not treat them, since you do not know the cause of it
I refuse to continue a dialogue with someone who cannot be bothered
to make their posts at least semi-coherent.
Jon.
Arnold Hendriks
> It seems there are two basic objections against using exceptions:
> 1. Making a program _really_ safe may require great efforts and may be
> non-trivial (see
> http://www.awlonline.com/cseng/meyerscddemo/DEMO/MAGAZINE/CA_FRAME.HTM )
I find exception-safety to be quite trivial as long as you stick to
the standard C++ containers. As long as you avoid new/delete as much as
possible, and make use of RAII (resource acquisition is initialization)
wherever possible for holding onto files and (multithreading) locks,
exception-safety comes without much programming effort.
> 2. Performance penalty. Any information on how exceptions slow down your
> program?
Performance penalty as opposed to programs that do their error checking
manually, or as opposed to programs that simply avoid error checking or
abort() on the sight of an error?
For example, it's probably cheaper to disable exception support and call
abort() on any malloc()/new failure. But if immediate fatal termination in
sight of an exception must be avoided, hand-coding cleanup code in the
sight of exceptions isn't likely to be faster, and very likely to be
error-prone, tedious and difficult to do.
--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/
Arnold Hendriks
>>
>> Handling errors helps prevent crashes. I don't see a real distinction
>> here.
> And by this you let the error exist in the code, at the end their are so
> many patches
> and bandaids in your code it is difficult to change it: since then you might
> experience
> the error that was covered up by the execption handling.
Why is it a coverup? Assume a simple HTTP server which has all functions
check pre- and postconditions. Now, we can handle incoming requests like
this:
try
{
connection->ProcessIncomingData(inbuffer,inbuffer_length);
}
catch (std::exception &e)
{
LogError(connection,e.what());
CloseConnection(connection);
}
If there is a bug in one of the functions ProcessIncomingData calls, that
is only rarely triggered and caught by pre- and postconditions check, at
least it won't take down the HTTP server (turning it into a DoS attack)
but allow it to happily remain running. And we have a log of what happened,
and can even dump the state of 'connection' and the incoming buffer if we
want.
<RANT>
On the other hand, I seriously detest Win32's approach of treating GPFs
as an exception. A GPF is generally causing an unrecoverable state (undefined
behaviour), while a C++ exception retains a recoverable state, as long as
all objects offer the basic exception-safety guarantees. Whoever thought
that was a reasonable behaviour for Win32 ought to be, well, erhm...
</RANT>
Michael Lacher
Just build in soime debug output into your exceptions, then you know
exactly where it was thrown, and why, and you can correct the problem,
and at the swame time you can make sure the program doesn't go berserk
on the user just because his PC dopped a bit in memory. I use
combination of TRACE() log file writing and an interrupt 3 (halts the
code when exception is thrown, like MFC exceptions) for debugging and it
works very fine. This way i can try/catch protect my main loop and at
least ensure proper shutdown after a problem and get good debug output
-> nearly no speed degradation.
Mucki
Michael Lacher
> As long as you avoid new/delete as much as
> possible,
hey, where is the fun in programming when everything is static ? ;-)
btw, i totally agree that exceptions are pretty simple and I love the
concept. makes error handling all the easier, especially with
polymorphism and when errorhandling a routine which calls subroutines
and you want to retry from start on an error in any level.
Mucki
Mathieu DESPRIEE
Hi all,
(almost) everybody in this thread talk about crashes, unexpected program
behaviour, defensive programming, etc...
IMHO, there's another good reason to use exceptions. Exception allows
you to decouple the error processing from the error itself.
Oftenly, you don't know how to handle an error at the place it appears.
But at a higher level, you DO know how to handle it.
For example, if a file doesn't exist, you can't read it. In your
very-low-level library, it's quite a serious error : you can't deal with
it. You throw your exception.
But at a higher level, at the place you asked to read the file, you
catch the exception : What ? The file I'm looking for does not exist ?
Fine, ok, I create it and assume I have no data to process.
I'm not learning anything to anybody saying this. IMHO, it's one of the
best interest of exception.
M.D
Arnold Hendriks
> Arnold Hendriks wrote:
>> As long as you avoid new/delete as much as
>> possible,
> hey, where is the fun in programming when everything is static ? ;-)
plenty of memory to continue running :)
But generally the STL containers and scoped_ptrs take care of most of my
memory needs.
> btw, i totally agree that exceptions are pretty simple and I love the
> concept. makes error handling all the easier, especially with
> polymorphism and when errorhandling a routine which calls subroutines
> and you want to retry from start on an error in any level.
Retry again from start? Wouldn't that just cause the error condition
again?
Michael Lacher
>> btw, i totally agree that exceptions are pretty simple and I love
>> the concept. makes error handling all the easier, especially with
>> polymorphism and when errorhandling a routine which calls
>> subroutines and you want to retry from start on an error in any
>> level.
>>
> Retry again from start? Wouldn't that just cause the error condition
> again?
>
Depends ... It might be an error condition which doesn't occur all the
time (like when reading data from a socket and you get a read error).
If the behaviour is totally deterministic you might change something
else (clear up more memory, etc ...) and then try again.
Mucki
Out of curiosity: Do you use a deep hierarchy of exceptions (like in
Java for example) or do you use only a few generic classes ?
Edwin Robert Tisdale
> Exceptions exist to handle unexpected problems.
Don't be silly.
You can't handle a problem that you don't expect.
Exceptions are events that you expect but can't predict.
The C++ exception handling mechanism
is one of the most abused features of the language.
Most C++ programmers simply throw an exception
when they don't know how to handle a problem
but there is no point in throwing an exception
unless it will be caught and can be handled
within the context of a calling function at some level.
You should always try to handle exceptions within the local scope.
This may involve calling a user defined exception handler
which will "fix-up" the exception, issue a diagnostic message
and/or exit from the program if the exception is fatal.
You should throw an exception only if it can't be handled
within the local context and can be handled by the calling function.
The exception object must contain all of the local information
required to handle the exception.
NotFound
> you don't, why not
>
>
> 1. Making a program _really_ safe may require great efforts and may be
> non-trivial (see
And not using exceptions makes this task easier?
NotFound
> can you treat the exception ?
> without knowing what hapenned ( the case if it is an unpredicted one ) how
> can you be sure you can go on with the program
> the integrity of the software is perhapslost without you knowing it.. better
> a crash in that case
I have, for example, a CGI program that catch all exceptions, for some
of it do a diagnostic and for the rest put a generic message. Better a
crash? Why?
NotFound
> is one of the most abused features of the language.
> Most C++ programmers simply throw an exception
> when they don't know how to handle a problem
> but there is no point in throwing an exception
> unless it will be caught and can be handled
> within the context of a calling function at some level.
Throwing an exception the resources alocated for the callers can be
freed. You can call this 'be handled'. of course.
> You should throw an exception only if it can't be handled
> within the local context and can be handled by the calling function.
And what do you know that? When you write a function you know all the
context when it is used?
Edwin Robert Tisdale
> And what do you know that?
> When you write a function, you know all the context when it is used?
When you write a function,
you MUST consider every context in which it might be used.
For example, suppose that you need to implement the square root function
double sqrt(double);
You could redefine the function so that it returns
the real part of sqrt(x) for all real x (i.e. 0 when x < 0).
but that would mask what is almost certainly
a programming error for x < 0.
Programming errors are never expected
so programmers never include code to catch and handle them
so it doesn't make any sense to through an exception.
What the library developer might do instead
is to provide a compile time option to detect
the programming error and report it to the application programmer:
// library.h
#include<math.h>
void report_error(char* file, int line, char* message);
double sqrt_error(double x, char* file, int line);
#ifdef ERRANT
#define sqrt(x) sqrt_error((x), __FILE__, __LINE__)
#endif
// library.c
#undef ERRANT
#include<library.h>
double sqrt_error(double x, char* file, int line) {
if (x < 0.0) {
report_error(file, line,
"In function sqrt(double), argument 1 is negative!");
}
return sqrt(x);
}
// gcc -O2 -I. -c library.c
The application programmer is obliged to provide an error reporting
function
// application.c
#include<library.h>
#include<stdio.h>
#include<errno.h>
void
report_error(char *file, int line, char *message) {
fprintf(stderr, "From %s:%d: %s\n", file, line, message);
fflush(stderr);
}
int
main(int argc, char* argv[]) {
fprintf(stdout, "%lf = sqrt(-4.0)\n", sqrt(-4.0));
fflush(stdout);
fprintf(stderr, "%d = errno\n", errno); fflush(stderr);
fprintf(stdout, "%lf = sqrt(+4.0)\n", sqrt(+4.0));
fflush(stdout);
fprintf(stderr, "%d = errno\n", errno); fflush(stderr);
return 0;
}
// gcc -I. -DERRANT -O2 -o application application.c library.o
-lm
and compile with option -DERRANT to get the library
to check for and report programming errors.
After testing and debugging and, the application can be recompiled
without error checking just before it is deployed.
Stuart Golodetz
I'd rather have a dubious error message than a hang, auto-reboot or BSOD to
be honest (that way I can at least debug it without waiting for 5 minutes to
reboot), but feel free to differ... And I think more highly of others'
programs which terminate gracefully, even with a programmed error message,
than ones which just crash for no apparent reason - it shows that the
programmer has made some sort of effort to prevent the user's computer going
beserk...
Cheers,
Stuart.
Stuart Golodetz
news:3C5EDD2D...@hobbiton.org...
He's confusing the generally accepted idea that it's better that your
program crashes than continues silently but outputs the wrong stuff, with
this situation, where errors can be handled gracefully, and all errors are
detected and the program can close itself without hanging the computer. I
think he assumes you mean continuing quietly with the program and
suppressing any error messages, which is certainly not a good idea. Wrong
end of the stick maybe?
HTH,
Stuart.
Kaz Kylheku
>Hi,
>
>what's your general opinion about exceptions? Do you use them, and if
>
>It seems there are two basic objections against using exceptions:
>
>1. Making a program _really_ safe may require great efforts and may be
>non-trivial (see
>
>2. Performance penalty. Any information on how exceptions slow down your
>program?
C++ exceptions are lacking in ability, but from that you cannot
generalize about exception handling in general.
In C++, when you catch an exception, the dynamic context is unwound
all the way up to that point. Thereby, important information about
the error is discarded before your handler even has a chance to do
anything.
When you look for an error in an interactive debugger, you like to
have the entire call trace which leads up to an error, so that you have
maximal information about what happened.
C++ exception handling takes the opposite approach: it throws away
the entire activation chain as it searches for a handler for the
exception.
The result is that exception handling, while useful, does not
live up to the full potential that can be obtained in an exception
handling system. There is more that can be done with error conditions
than merely to *contain* them.
One nice thing for an error handler to be able to do is to inquire
whether it's possible to continue execution after the error, and in
what ways.
Suppose that function A calls function B, which calls function C.
Suppose that C throws an error, but B knows how to continue working
after such an error. In C++ exception handling, this means that B has to
catch that error and continue working. But doing so hides the error from
A; A has no say in how the error is handled. This is quite rude,
because B is a subcontractor working for A, and it's taking important
decisions which affect A into its own hands, so to speak.
In Common Lisp, I can catch the error in A instead, and write B
so that it provides something called a ``restart'' (or several
restarts, if applicable). Restarts do not catch the error, they
are simply available. When A's error handler is called, the
unwinding does not yet take place, so the handler can search for
the restarts made available by B which surround the condition being
raised in C. A can make the decision whether or not to invoke an
available restarts and which one. So the decision making and expertise
can be put into the right places. B provides A with a list of technical
alternatives, based on which A can make a high level decision. You have
the capability to build a sophisticatd protocol for dealing with problems.
If assistance from a human is required, it is A that can bring up the
dialog box, or text based prompt. You don't have to confound the B
implementation with user interface details, or even knowledge of a user
interface protocol. (Why should a low level file access object know how
to bring up an ``abort, retry'' dialog box?) And you don't have to turn
B into a state machine that knows how to restart itself after indicating
an error; B can be entirely procedural.
With restarts can interactively refine your program's error handling
protocols and strategies until you reach a level of robustness that
will *shock* users that are accustomed to flaky C++ software that just
gives up and exits, or otherwise bails to an inappropriate place.
I'm going through such a refinement process with a freeware version
control tool I'm working on called Meta-CVS. Within Meta-CVS, it can
happen, for instance, for that some low-level iteration that is walking
a directory tree raises a condition, like maybe due to not being able
to descend into a directory due to insufficient permission. A handler in
the topmost function of the program catches that and decides whether to
continue or not. Right now there is some crude interaction to allow the
user to determine what happens, but this will get better. The existing
handler was hacked up literally minutes before I shipped the alpha version
0.0 and does exactly the intended thing, because I had already interacted
with the error system in the debugger prior to that; effectively the
Lisp environment provided me with a ``deluxe'' top level handler,
but I wanted to give the user something very simple that distils
everything down to three simple choices, and does not drop them into
the debugger. Later on, I can do something cool, like have a way for
the user to request that some failed operation be repeated. Bad permission
on a file? We don't have to stop, just let the user go in there and fix
it using another window, then tell the progrma to try it again. The retry
restart can be built into a few of the the very lowest level file system
operations, and the user interface for it in the highest level
function. Bam, instantly you give the user retry ability everywhere in
the program, without changing any of the middle bits. The highest and
lowest levels cooperating in perfect harmony. Want a graphical UI instead?
Replace just the top level.
When I first learned about restarts, a big light bulb went on: ``Aha!''.
I suddenly realized everything that is wrong with C++-style exceptions,
and why they are never seem like a satisfactory solution. What you need
in some situations is error handling that is logically separated from
unwinding. Lisp has throw and catch but they have nothing to do with
the condition system; they are a dynamic, non-local control transfer
mechanism, something a handler can use when it decides to accept the
condition. C++ exceptions are only good for simple error situations
from which there is no obvious way to recover at a lower level than the
actual handler.
An example of where C++ exception handling works is, say, catching a
garbled request datagram coming into a server. You can just catch that in
the service loop and dispatch the receive of the next datagram. There is
nobody to inform, no decision to make between different layers, nothing.
It's really just an optimized way of returning, knowing that the garbled
datagram is of no consequence. (In fact there is restart logic---the
retransmit timer in the client. ;)
NotFound
>
> When you write a function,
> you MUST consider every context in which it might be used.
You must define its behavior, the use is a concern of the user.
> Programming errors are never expected
> so programmers never include code to catch and handle them
Perhaps i'm not a programmer, then?
> so it doesn't make any sense to through an exception.
In sqrt, a C library function, certainly not.
> What the library developer might do instead
> is to provide a compile time option to detect
> the programming error and report it to the
> application programmer:
To detect a runtime error in compile time?
> and compile with option -DERRANT to get the library
> to check for and report programming errors.
> After testing and debugging and, the application can be recompiled
> without error checking just before it is deployed.
And you test and debug with every possible user entry and system
environment?
NotFound
> > of it do a diagnostic and for the rest put a generic message. Better a
> > crash? Why?
> He's confusing the generally accepted idea that it's better that your
> program crashes than continues silently but outputs the wrong stuff, with
Is possible, but i don't understand this confusion betewn "throw an
exception" and "continues silently". The second can be made with the
first, but also without excpections.
> I think he assumes you mean continuing quietly with the program and
> suppressing any error messages, which is certainly not a good idea.
Well, if one discuss what he presumes the other is thinking instead of
what the other is saying... ;)
NotFound
> have the entire call trace which leads up to an error, so that you have
> maximal information about what happened.
> C++ exception handling takes the opposite approach: it throws away
You can use a debugger that halts in a throw, it's not entirely
opposite.
> condition. C++ exceptions are only good for simple error situations
> from which there is no obvious way to recover at a lower level than the
> actual handler.
If the actual handler cannot handle an exception throws it, nothing
prevents the upper level from catch and handle it and eventually
recover.
Kaz Kylheku
>> When you look for an error in an interactive debugger, you like to
>> have the entire call trace which leads up to an error, so that you have
>> maximal information about what happened.
>> C++ exception handling takes the opposite approach: it throws away
>
>You can use a debugger that halts in a throw, it's not entirely
>opposite.
The semantics are opposite. Of course, the C++ language doesn't define
any debugging support. The semantics are that when you catch,
things are unwound.
>> condition. C++ exceptions are only good for simple error situations
>> from which there is no obvious way to recover at a lower level than the
>> actual handler.
>
>If the actual handler cannot handle an exception throws it, nothing
>prevents the upper level from catch and handle it and eventually
>recover.
You obviously didn't understand anything I wrote. That's normal; you
can't think outside of a C++ box instantly. It takes time.
There can be different levels of recovery. You can recover after an
accident, and come out of the hospital healthy, but with two legs missing
and half your memory gone. You recovered from some aspects of the trauma,
but you did not regain anything close to what you were before. You only
recovered from the immediately life-threatening conditions of the trauma;
you didn't die.
This kind of recovery, containment of death, is a very low expectation
to have of error handling. It's a minimum requirement, because lack
of recovery means that the program crashes or otherwise terminates.
Preventing these problems in C++ programs is hard, so it's hard for
people in C++ trenches to see a few steps a head of solving these basic
program survival problems.
Cy Edmunds
"Heiko Gottschling" <nos...@ottomalotto.de> wrote in message
news:3C5E67BC...@ottomalotto.de...
> Hi,
>
> what's your general opinion about exceptions? Do you use them, and if
> you don't, why not?
I use them all the time.
>
> It seems there are two basic objections against using exceptions:
>
> 1. Making a program _really_ safe may require great efforts and may be
> non-trivial (see
> http://www.awlonline.com/cseng/meyerscddemo/DEMO/MAGAZINE/CA_FRAME.HTM )
>
Of course. But are exceptions some sort of barrier? Compared to what?
> 2. Performance penalty. Any information on how exceptions slow down your
> program?
If you throw an exception and don't catch it your program will slow down. A
lot.
The old C style is to have every function return an error code:
if (first_func())
{
handle_error();
return;
}
else
{
if (second_func())
{
// and so forth
Aside from concealing the logic of your program by making it look like a
bunch of error checks, this style uses CPU time every call to check the
error return value. Worse yet, if the function actually returns a result in
addition to the error code you have to use a pointer in the argument list,
always a cause of confusion. And of course some C functions return 0 when
everything is OK and some return 1 when everything is OK...
With exceptions your functions simply return the results of their
calculations and error handling is done separately. The amount of state
information returned by your exception for diagnostic or recovery purposes
is up to you. If you just want error messages you can use:
try {
first_function();
second_function();
} catch (std::exception e) {
ShowMsg(e.what());
}
The overhead for this is negligible in most cases.
Cy
@wanadoo.fr dwarfpower
"NotFound" <bla...@hobbiton.org> a écrit dans le message de news:
3C5EDD2D...@hobbiton.org...
Why a crash?
I could answer why not a crash, but i think we wouldn't go any further.
first of all, adding code without any added value is in itself open to
discussion. As i said earlier,
a message like "unexpected error occured" as no added value, ( except if you
have specific needs
regarding crashes ), neither for a user perspective or for a evelopper one.
then on a developper perspective, generic catching make it difficult to
trace the origin of unexpected
exception. once you are in the catch statement, you cannot go back to the
origin of exception
you cannot know the state of the machine while generating the exception.. in
other world you reduce
the amount of information given to you to understand what happened
@wanadoo.fr dwarfpower
"Stuart Golodetz" <sgol...@dial.pipex.com> a écrit dans le message de
news: 3c5ef9e3$0$8506$cc9e...@news.dial.pipex.com...
except in very particular fields( hardware drivers and stuff like that) it
is very unlikely that
a problem in your program that could have been caught with exception
mechanism but was not
should result in OS unstability
Jon Bills
> Jon Bills wrote:
>
> > Exceptions exist to handle unexpected problems.
>
> Don't be silly.
I'm not being silly.
> You can't handle a problem that you don't expect.
I didn't say you could, but allowing the application to terminate is a
better
option than allowing undefined behaviour. Just in case you missed the
context,
I was replying to someone who seemed to think it acceptable for an
application to crash.
[snip]
Jon.
@wanadoo.fr dwarfpower
> > > Exceptions exist to handle unexpected problems.
> >
> > Don't be silly.
>
> I'm not being silly.
>
> > You can't handle a problem that you don't expect.
>
> I didn't say you could, but allowing the application to terminate is a
> better
> option than allowing undefined behaviour. Just in case you missed the
> context,
> I was replying to someone who seemed to think it acceptable for an
> application to crash.
>
> [snip]
just a simple question. what are you doing with signals ? do you trap them
also
to terminate your application properly ?an unexpected exception is just the
same
as a segment violation a memory fault or any other problem of that kind.
whatever you do you cannot avoid crashes, so just accept them
Stephen Howe
>
> > Exceptions exist to handle unexpected problems.
>
> Don't be silly.
He is not being silly.
The catch(...) clause is to catch unexpected exceptions. Occasionally my
code has ended in this clause and before this I have catch handlers for all
the types of exception I am expecting.
Stephen Howe
Peter Koch Larsen
[snip]
> You obviously didn't understand anything I wrote. That's normal; you
> can't think outside of a C++ box instantly. It takes time.
"restart-point" could easily be made in C++, e.g. by calling a
usersupplied errorhandler (common in some scenarios). What is
important here is that when you program in C++, the "restart point" is
implemented in terms of the catch. In your scenario, where A calls B
calls C, B SHOULD be able to handle the exception in C properly. If it
does not, it should let A handle the exception. Where LISP has
retrypoints, i guess that most probably you would implement the same
functionality by having a group of "B"-functions and call these
successively (or having a B-object with its own state). For clarity of
programcode, I (as a C++ programmer) would probably prefer this
scenario, but i welcome any sourcecode to demonstrate the viability of
"restartpoints".
>
> There can be different levels of recovery. You can recover after an
> accident, and come out of the hospital healthy, but with two legs missing
> and half your memory gone. You recovered from some aspects of the trauma,
> but you did not regain anything close to what you were before. You only
> recovered from the immediately life-threatening conditions of the trauma;
> you didn't die.
>
> This kind of recovery, containment of death, is a very low expectation
> to have of error handling. It's a minimum requirement, because lack
> of recovery means that the program crashes or otherwise terminates.
>
> Preventing these problems in C++ programs is hard, so it's hard for
> people in C++ trenches to see a few steps a head of solving these basic
> program survival problems.
the problems i have found in C++ programs originate in programmers
adhering to follow basic C++ idioms (such as RAII). I have never had
problems with errorhandling in my programs, and - yes: i have written
code that had to be reliable, had to be able to run in degraded
environments and had to fail in a predictable manner. Exceptions are a
very elegant way out of here.
Peter
Daniel T.
>what's your general opinion about exceptions? Do you use them, and if
>you don't, why not?
In general, an exception should be thrown by a function when the
parameters passed to it are valid but the function was still unable to
do its assigned job.
>It seems there are two basic objections against using exceptions:
>
>1. Making a program _really_ safe may require great efforts and may be
>non-trivial (see
>http://www.awlonline.com/cseng/meyerscddemo/DEMO/MAGAZINE/CA_FRAME.HTM )
Making a program _really_ safe does require great effort and is
non-trivial, but that isn't a valid argument *against* using exceptions.
Exceptions guarentee that problems won't be ignored. The article you
site is very old and only serves to show that, in order to make code
deal correctly with exceptions, one must have experience using them.
That can be said about any error handling strategy.
>2. Performance penalty. Any information on how exceptions slow down your
>program?
They don't slow down your program any more than any other, equally
effective, error handling strategy.
Peter Koch Larsen
> Hi,
>
> you don't, why not?
>
>
> 1. Making a program _really_ safe may require great efforts and may be
> non-trivial (see
> http://www.awlonline.com/cseng/meyerscddemo/DEMO/MAGAZINE/CA_FRAME.HTM )
>
> program?
>
> Heiko
Hello Heiko
I just love exceptions. They are one of the most important parts of
the C++ language and team up with deterministic desctruction to allow
you to easily write robust code.
1. I agree it can be difficult to write robust code, but using
exceptions makes it easier - not more difficult. The reason is that
exceptions take the burden off the programmer: code can be written
with most errorhandling taken off the normal flow of the program,
making the program far more readable, easier to write and easier to
maintain. Example:
// c++ w. exceptions:
void func()
{
file f("in");
network n("out");
// do operation on f and network.... e.g. copying from f to n
while (!f.eof()) n.op();
}
// c++ wo. exceptions:
void func()
{
file f("in");
if (f.okay())
{
network n("out");
if (n.okay())
{
// do operation on f and network.... e.g. copying from f
to n
while (f.okay() && n.okay() && !f.eof() && n.op())
continue;
}
}
}
Notice that half of the code in func now is concerned with
errorhandling, and a very incomplete one actually: No errors are ever
reported to the caller, for example, and no errorcode is maintained so
at best only a boolean errorcode could be returned.
With regard to performance, exception should occur no overhead
whatsoever when they do not occur. If they DO occur, the overhead
should be in the range of that of a functioncall. Compare this to the
"exception-free" func above. A lot of code is involved with this
checking for faults. Morale: use exceptions if you want to write fast
and robust code.
Peter
Alexander Terekhov
[...]
> C++ exceptions are lacking in ability, but from that you cannot
> generalize about exception handling in general.
>
> In C++, when you catch an exception, the dynamic context is unwound
> all the way up to that point. Thereby, important information about
> the error is discarded before your handler even has a chance to do
> anything.
>
> When you look for an error in an interactive debugger, you like to
> have the entire call trace which leads up to an error, so that you have
> maximal information about what happened.
>
> C++ exception handling takes the opposite approach: it throws away
> the entire activation chain as it searches for a handler for the
> exception.
>
> The result is that exception handling, while useful, does not
> live up to the full potential that can be obtained in an exception
> handling system. There is more that can be done with error conditions
> than merely to *contain* them.
>
> One nice thing for an error handler to be able to do is to inquire
> whether it's possible to continue execution after the error, and in
> what ways.
"15.1 Throwing an exception
1 Throwing an exception transfers control to a handler.
An object is passed and the type of that object
determines which handlers can catch it."
To me, this just means that my handler is either able
to FULLY handle the exception (perhaps adjust subsequent
program logic/behavior or report an error/ask user for a
retry or do something like that) ENTIRELY based on local
context, type of exception object and any custom information
it carries, or will just perform the "local recovery/cleanup"
and will *re-throw* afterwards. The latter is usually NOT
needed with proper use of C++ auto-objects/RAII/DoIt-
UndoIt -- exception safety mechanisms which help to
achieve exception safety without any catches.
Now, the standard also says:
"9 If no matching handler is found in a program, the function
terminate() is called; whether or not the stack is unwound
before this call to terminate() is implementation-defined
(15.5.1)." ^^^^^^^^^^^^^^^^^^^^^^
"[lib.terminate] 18.6.3.3 terminate
void terminate();
1 Called by the implementation when exception handling
must be abandoned for any of several reasons
(15.5.1). May also be called directly by the program.
2 Effects: Calls the terminate_handler function in effect
immediately after evaluating the throw-expression
(18.6.3.1), if called by the implementation, or calls
the current terminate_handler function, if called by
the program."
"[lib.terminate.handler] 18.6.3.1 Type terminate_handler
typedef void (*terminate_handler)();
1 The type of a handler function to be called by
terminate() when terminating exception processing.
2 Required behavior: A terminate_handler shall terminate
execution of the program without returning to the caller.
3 Default behavior: The implementation's default
terminate_handler calls abort()."
^^^^^^^
So, to me, you won't *necessarily* (that is QoI issue,
I guess) loose any meaningful information if it will
turn out that your program just does not know how to
HANDLE an exception thrown/re-thrown on some of its
layers!
> Suppose that function A calls function B, which calls function C.
> Suppose that C throws an error, but B knows how to continue working
> after such an error. In C++ exception handling, this means that B has to
> catch that error and continue working. But doing so hides the error from
> A; A has no say in how the error is handled. This is quite rude,
> because B is a subcontractor working for A, and it's taking important
> decisions which affect A into its own hands, so to speak.
>
> In Common Lisp, I can catch the error in A instead, and write B
> so that it provides something called a ``restart'' (or several
> restarts, if applicable). Restarts do not catch the error, they
> are simply available. When A's error handler is called, the
> unwinding does not yet take place, so the handler can search for
> the restarts made available by B which surround the condition being
> raised in C. A can make the decision whether or not to invoke an
> available restarts and which one. So the decision making and expertise
> can be put into the right places. B provides A with a list of technical
> alternatives, based on which A can make a high level decision. You have
> the capability to build a sophisticatd protocol for dealing with problems.
In C++, I would just declare/implement appropriate
non-"nothrow" exception safety guarantee ("basic"
or "strong") for my B/C... and just let A (or any
other B caller) decide what he or she wants to do
with all possible KNOWN exceptions (unknown/unexpected
should be handled by terminate()->abort() handler ;-))
thrown from its calling chain, given provided safety
guarantee; unless I really want to HIDE the occurrence
of particular exception(s) *I know how to handle* --
that is why I just catch this and/or that exception and
do NOT *re-throw*; in other words, my catching/handling
is just a part of my subcontractor's CONTRACT, which
you might even want to make/define as the runtime policy,
if you really need/like it!
Do you see any problems with this approach?
regards,
alexander.
P.S. Kaz, are there any chances/plans that you or some
other linux*threads* developer/maintainer would address
the issue of thread-cancellation/thread-exit
(pthread_exit) and *C++*-stack-unwinding? ;-)
Edwin Robert Tisdale
> The catch(...) clause is to catch unexpected exceptions.
> Occasionally my code has ended in this clause
> and before this I have catch handlers
> for all the types of exception I am expecting.
You are confused.
Unpredictable does not mean the same thing as unexpected.
The very fact that you include a catch(...) clause
means that you expected other exceptions
even if you could not predict what they would be.
Otherwise, the catch(...) clause would be superfluous.
jeffc
news:a3lroa$194soj$1...@ID-123884.news.dfncis.de...
>
> "Heiko Gottschling" <nos...@ottomalotto.de> wrote in message
> news:3C5E67BC...@ottomalotto.de...
> > Hi,
> >
> > what's your general opinion about exceptions? Do you use them, and if
> > you don't, why not?
> >
>
> crashes where it crashes, and one can see which code line. The exception
> call let it jump to the end of the try catch block and then one does
> not know where the error is.
You do a lot of industrial strength programming I take it, Marc?
jeffc
> > Exceptions are one means of achieving graceful degradation in the face
> > of error. The point is not just to provide information to the developer,
> > but also to behave sensibly for the user.
> >
>
> I think if the exeption result unexpected behaviour I can not say much more
> then "Houston we have a mayor malfunction", which only masks the error,
> and only looks a bit better from the outside.
I'm afraid you're confused as to the use of exceptions in the real world.
Maybe in your computer science lab it's easier to let the program crash with a
debugger.
jeffc
>
> > Exceptions exist to handle unexpected problems.
>
> Don't be silly.
>
> You can't handle a problem that you don't expect.
Define "handle".
> The C++ exception handling mechanism
> is one of the most abused features of the language.
That's irrelevant.
> Most C++ programmers simply throw an exception
> when they don't know how to handle a problem
> but there is no point in throwing an exception
> unless it will be caught and can be handled
> within the context of a calling function at some level.
First, you can always do something with catch(...). Second, even a thrown
exception that is not explicitly handled is better than a random crash, or an
error that will cause a crash in some other part of the program.
> You should always try to handle exceptions within the local scope.
Not necessarily. It's perfectly reasonable to put a lot of exception handling
at a higher level, all together and removed from the much of the code.
jeffc
Pedantic. No, it does not mean you expected other errors. It's just a means
toward organizing potential problems. When do you ever *expect* an error?
You're trying to carry on an argument for no good purpose here.
jeffc
news:KkD78.23794$Jq.11...@news2.calgary.shaw.ca...
> Suppose that function A calls function B, which calls function C.
> Suppose that C throws an error, but B knows how to continue working
> after such an error. In C++ exception handling, this means that B has to
> catch that error and continue working. But doing so hides the error from
> A; A has no say in how the error is handled. This is quite rude,
> because B is a subcontractor working for A, and it's taking important
> decisions which affect A into its own hands, so to speak.
What is so hard about B handling the exception and then rethrowing it to A?
jeffc
news:notdanielt3-C55C...@paloalto-snr1.gtei.net...
> Heiko Gottschling <nos...@ottomalotto.de> wrote:
>
> >what's your general opinion about exceptions? Do you use them, and if
> >you don't, why not?
>
> In general, an exception should be thrown by a function when the
> parameters passed to it are valid but the function was still unable to
> do its assigned job.
Do you mean to imply that if the parameters are invalid, exceptions should not
be thrown?
Arnold Hendriks
>>If the actual handler cannot handle an exception throws it, nothing
>>prevents the upper level from catch and handle it and eventually
>>recover.
> You obviously didn't understand anything I wrote. That's normal; you
> can't think outside of a C++ box instantly. It takes time.
the new operator should retry an allocation if the allocation-failure
handler exists without throwing an exception. This allows that handler
to free up some memory, and have new retry the allocation.
> There can be different levels of recovery. You can recover after an
> accident, and come out of the hospital healthy, but with two legs missing
When you recover from the accident, you can retry what you were attempting
to do ( while (!success) { try .. catch .. } ), or give up trying. I don't
see how those concepts wouldn't exist in C++. You can't automatically go
back to the point of failure and retry, but when things go wrong and may
be in an unpredictable state, it might be safer anyway to restart from
the last checkpoint.
--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/
Edwin Robert Tisdale
> No, it does not mean you expected other errors.
> It's just a means toward organizing potential problems.
> When do you ever *expect* an error?
> You're trying to carry on an argument for no good purpose here.
No. You can't handle programming errors (bugs)
except by fixing the code that causes the error.
Exception handling is about expected but unpredictable events
which the programer cannot practically prevent.
The C++ exception handling mechanism is designed
to deal specifically with events that cannot be handled
a the point where they occur but can be handled
by a calling function at some level.
Donovan Rebbechi
>
> "Heiko Gottschling" <nos...@ottomalotto.de> wrote in message
> news:3C5E67BC...@ottomalotto.de...
>> Hi,
>>
>> you don't, why not?
>>
>
> crashes where it crashes, and one can see which code line. The exception
> call let it jump to the end of the try catch block and then one does
> not know where the error is.
Put a breakpoint in your base exception class constructor, and then you
can get a full backtrace. BTW, an exception is slightly more useful than
a crash, because the point at which the crash occurs is very unpredictable,
while one can use exceptions to pre-empt crashes.
BTW, if you're writing your own "external libraries", you will almost always
need exceptions. That or C-style "error codes". And if you're writing anything
non-trivial, that implies you're writing some library code.
HTH,
--
Donovan
Donovan Rebbechi
>
> "dwarfpower" <dwarf.power @ wanadoo.fr> wrote in message
>> >
>> > Exceptions exist to handle unexpected problems.
>> >
>> >
>> No they exists to handle expected ones
>>
>
> Agreed, the unexpected ones need to crash, better crash good and repair then
> a bandaid exception handling that covers up the error!
The role of exceptions are not to "cover up errors". You can use them to catch
errors before they result in a "crash". Since the program is usually in a
reasonable state when the exception occurs, you are in a reasonable position
to query the stack and find out what went wrong.
--
Donovan
Donovan Rebbechi
> NotFound wrote:
> Programming errors are never expected
> so programmers never include code to catch and handle them
During debugging and testing, programming errors are expected. Only an arrogant
fool would just assume their code is correct.
During testing, I put everything inside main() in a try/catch block, then
use breakpoints in exception constructors to track down errors.
--
Donovan
Donovan Rebbechi
>> >
> just a simple question. what are you doing with signals ? do you trap them
> also to terminate your application properly ?an unexpected exception is just
> the same as a segment violation a memory fault or any other problem of that
> kind.
>
> whatever you do you cannot avoid crashes, so just accept them
The same illogic implies that we should not have law enforcement because
"you cannot avoid crime".
--
Donovan
Donovan Rebbechi
>
> "Jon Bills" <jon_...@hotmail.com> wrote in message
> news:ae450774bafdb72ba7b...@mygate.mailgate.org...
>> > >
>> > exception is a mean for diagnostic, a way to deal with errors not
> crashes
>>
>> Handling errors helps prevent crashes. I don't see a real distinction
>> here.
>>
>
> And by this you let the error exist in the code, at the end their are so
> many patches
> and bandaids in your code it is difficult to change it: since then you might
> experience
> the error that was covered up by the execption handling.
Why do you keep mindlessly quacking about this ? No-one is advocating using
exception handling to "cover up" bugs.
--
Donovan
Donovan Rebbechi
> No i just say that crashes should not be artificially avoided
> if after an error occured you can recover from the exception then
> it was a predictable error, so it is not a bug
>
> can you treat the exception ?
Run a backtrace with your debugger. This process can even be (and sometimes is)
automated, so beta testers can include it in a bug report.
> without knowing what hapenned ( the case if it is an unpredicted one ) how
> can you be sure you can go on with the program
> the integrity of the software is perhapslost without you knowing it.. better
> a crash in that case
What do you mean "without you knowing it" ? Throwing an exception doesn't
do nothing.
--
Donovan
Donovan Rebbechi
> In article <3C5E67BC...@ottomalotto.de>, Heiko Gottschling wrote:
> C++ exceptions are lacking in ability, but from that you cannot
> generalize about exception handling in general.
>
> In C++, when you catch an exception, the dynamic context is unwound
> all the way up to that point. Thereby, important information about
> the error is discarded before your handler even has a chance to do
> anything.
>
> When you look for an error in an interactive debugger, you like to
> have the entire call trace which leads up to an error, so that you have
> maximal information about what happened.
>
> C++ exception handling takes the opposite approach: it throws away
> the entire activation chain as it searches for a handler for the
> exception.
Put a break point in the construction of the base class of your exception.
Works like charm for me, at least in gdb.
Of course, if you don't have a backtrace, the exception is, as you say, not
terribly useful as a debugging tool.
> Suppose that function A calls function B, which calls function C.
> Suppose that C throws an error, but B knows how to continue working
> after such an error. In C++ exception handling, this means that B has to
> catch that error and continue working. But doing so hides the error from
> A; A has no say in how the error is handled. This is quite rude,
B can rethrow in situations where the "success" of B is questionable.
> In Common Lisp, I can catch the error in A instead, and write B
> so that it provides something called a ``restart'' (or several
> restarts, if applicable). Restarts do not catch the error, they
> are simply available.
How is this different from a try/catch/rethrow ?
--
Donovan
Edwin Robert Tisdale
> Do you mean to imply that, if the parameters are invalid,
> exceptions should not be thrown?
That is correct.
If the application programmer passes an invalid parameter to a library function
it is almost certainly a programming error (bug).
There is no practical way for the library function to handle programming errors.
All it can do is issue a diagnostic message to the application programmer
while the application is being tested and debugged.
Once the application programmer has finished testing and debugging,
there is no point in having the library function check for invalid parameters.
Application programmers are always responsible for passing valid parameters.
If they aren't going to check the parameters before they pass them,
there is no reason to expect that they will check a returned error code
or catch an exception thrown because they passed an invalid parameter.
Edwin Robert Tisdale
> During debugging and testing, programming errors are expected.
> Only an arrogant fool would just assume their code is correct.
Now that's just silly.
I try to fix all of the programming errors (bugs) that I know about
before I begin testing. I expect that you do the same.
You are simply hoping that your testing will expose unexpected
(or simply forgotten) programming errors so that you can fix them.
> During testing, I put everything inside main() in a try/catch block,
> then I use breakpoints in exception constructors to track down errors.
Good for you!
But that extra code is superfluous once you have finished testing and debugging.
It just makes your code harder to read, understand and maintain.
Daniel T.
>"Daniel T." <notda...@gte.net> wrote in message
>> Heiko Gottschling <nos...@ottomalotto.de> wrote:
>>
>> >what's your general opinion about exceptions? Do you use them, and if
>> >you don't, why not?
>>
>> In general, an exception should be thrown by a function when the
>> parameters passed to it are valid but the function was still unable to
>> do its assigned job.
>
>Do you mean to imply that if the parameters are invalid, exceptions should not
>be thrown?
Yes, as a matter of fact I do. It is the calling code's responsibility
to ensure that the parameters passed into a function are valid according
to the documentation of that function. If they are not, then the
function cannot guarantee *any* result, much less a properly thrown
exception.
If you wish, you may argue that the programmer should write functions so
that any object of the proper type is a valid parameter. I think that
this sort of restriction is too strong. In some cases, I don't think
that the language proper allows you the freedom to make such guarantees
at *any* price. (For example, if a function accepts a pointer to an int
as a parameter, can the function gracefully handle a situation where the
pointer points to an invalid block of memory?)
NotFound
> discussion. As i said earlier, a message like "unexpected error occured"
> as no added value, ( except if you have specific needs regarding crashes ),
> neither for a user perspective or for a evelopper one.
No added value? Is then the same that dead whitout a word?
> then on a developper perspective, generic catching make it difficult to
> trace the origin of unexpected exception. once you are in the catch statement,
> you cannot go back to the origin of exception you cannot know the state of the
> machine while generating the exception.. in other world you reduce the amount
> of information given to you to understand what happened
Do you talk about examining a core dump of the dead program? Well, if
this if your system of find bugs, then a exception certainly does not
help.
NotFound
> >be thrown?
> Yes, as a matter of fact I do. It is the calling code's responsibility
> to ensure that the parameters passed into a function are valid according
> to the documentation of that function. If they are not, then the
> function cannot guarantee *any* result, much less a properly thrown
> exception.
According to the documentation. That documentation can specify that some
entries generates an exception
> that any object of the proper type is a valid parameter. I think that
> this sort of restriction is too strong. In some cases, I don't think
In some cases, not always.
Regards.
@wanadoo.fr dwarfpower
hardly unexpected/able then
"Donovan Rebbechi" <elf...@panix.com> a écrit dans le message de news:
slrna60890....@panix2.panix.com...
Donovan Rebbechi
> Donovan Rebbechi wrote:
>
>> During debugging and testing, programming errors are expected.
>> Only an arrogant fool would just assume their code is correct.
>
> Now that's just silly.
> I try to fix all of the programming errors (bugs) that I know about
> before I begin testing. I expect that you do the same.
Yes, one can try, but unless the software is fairly trivial, you won't be able
to catch all programming errors prior to release. How many major software
packages do you know of where the release contained no bugs ?
> You are simply hoping that your testing will expose unexpected
> (or simply forgotten) programming errors so that you can fix them.
Yep. That's one thing testing can do.
>> During testing, I put everything inside main() in a try/catch block,
>> then I use breakpoints in exception constructors to track down errors.
>
> Good for you! But that extra code is superfluous once you have finished
> testing and debugging.
What does it mean to "finish debugging" , and how do you determine when you
have "finished" ?
> It just makes your code harder to read, understand and maintain.
If you cannot read or maintain code with a single try/catch block in main(),
you are not a competent C++ programmer.
--
Donovan
jeffc
> jeffc wrote:
>
> > No, it does not mean you expected other errors.
> > It's just a means toward organizing potential problems.
> > When do you ever *expect* an error?
> > You're trying to carry on an argument for no good purpose here.
>
> No. You can't handle programming errors (bugs)
> except by fixing the code that causes the error.
Again, a red herring. What does "handle" mean? Obviously, there's one thing
you do as the program is running, and another thing you do to change the
program after you realize there's a bug. You can very easily "handle" a
potential problem with code that might have a comment like "I don't expect to
get here - if I do there must be some bug. Die with dignity and grace."
> Exception handling is about expected but unpredictable events
> which the programer cannot practically prevent.
Again, pedantic. I could just as easily reword that to
"Exception handling is about predictable but unexpected events which the
programmer cannot practically prevent." You cannot have an expectation of
something happening that you have no prediction of happening.
> The C++ exception handling mechanism is designed
> to deal specifically with events that cannot be handled
> a the point where they occur but can be handled
> by a calling function at some level.
Basically agree, depending on your definition of "handled".
jeffc
> "jeffc" <sp...@not.com> wrote:
>
> >"Daniel T." <notda...@gte.net> wrote in message
> >> Heiko Gottschling <nos...@ottomalotto.de> wrote:
> >>
> >> >what's your general opinion about exceptions? Do you use them, and if
> >> >you don't, why not?
> >>
> >> In general, an exception should be thrown by a function when the
> >> parameters passed to it are valid but the function was still unable to
> >> do its assigned job.
> >
> >Do you mean to imply that if the parameters are invalid, exceptions should
not
> >be thrown?
>
> Yes, as a matter of fact I do. It is the calling code's responsibility
> to ensure that the parameters passed into a function are valid according
> to the documentation of that function. If they are not, then the
> function cannot guarantee *any* result, much less a properly thrown
> exception.
That is *precisely* the reason for using exceptions - the function cannot
guarantee any result (that it was asked for.)
> If you wish, you may argue that the programmer should write functions so
> that any object of the proper type is a valid parameter. I think that
> this sort of restriction is too strong. In some cases, I don't think
> that the language proper allows you the freedom to make such guarantees
> at *any* price. (For example, if a function accepts a pointer to an int
> as a parameter, can the function gracefully handle a situation where the
> pointer points to an invalid block of memory?)
Certainly. Another example: most programmers do not handle "out of memory"
errors after invoking "new". It doesn't mean they shouldn't.
jeffc
> jeffc wrote:
>
> > Do you mean to imply that, if the parameters are invalid,
> > exceptions should not be thrown?
>
> That is correct.
> If the application programmer passes an invalid parameter to a library
function
> it is almost certainly a programming error (bug).
> There is no practical way for the library function to handle programming
errors.
> All it can do is issue a diagnostic message to the application programmer
> while the application is being tested and debugged.
First you say there's no practical way to handle it, then you give a way to
handle it. There's no law that says you can't leave checks for that sort of
thing in.
> Once the application programmer has finished testing and debugging,
> there is no point in having the library function check for invalid
parameters.
>
> Application programmers are always responsible for passing valid parameters.
> If they aren't going to check the parameters before they pass them,
> there is no reason to expect that they will check a returned error code
> or catch an exception thrown because they passed an invalid parameter.
It doesn't matter what they'll do. There's never any guarantee that your
caller, or anyone up the call path, will catch any exception. That has
nothing to do whatsoever with whether or not you should throw them.
@wanadoo.fr dwarfpower
"NotFound" <bla...@hobbiton.org> a écrit dans le message de news:
3C603BEB...@hobbiton.org...
> > first of all, adding code without any added value is in itself open to
> > discussion. As i said earlier, a message like "unexpected error occured"
> > as no added value, ( except if you have specific needs regarding
crashes ),
> > neither for a user perspective or for a evelopper one.
>
> No added value? Is then the same that dead whitout a word?
>
> > then on a developper perspective, generic catching make it difficult to
> > trace the origin of unexpected exception. once you are in the catch
statement,
> > you cannot go back to the origin of exception you cannot know the state
of the
> > machine while generating the exception.. in other world you reduce the
amount
> > of information given to you to understand what happened
>
> Do you talk about examining a core dump of the dead program? Well, if
> this if your system of find bugs, then a exception certainly does not
> help.
you have a debugger you know , and core file are really usefull sometime
Daniel T.
NotFound <bla...@hobbiton.org> wrote:
>> >Do you mean to imply that if the parameters are invalid, exceptions should
>> >not
>> >be thrown?
>> Yes, as a matter of fact I do. It is the calling code's responsibility
>> to ensure that the parameters passed into a function are valid according
>> to the documentation of that function. If they are not, then the
>> function cannot guarantee *any* result, much less a properly thrown
>> exception.
>
>According to the documentation. That documentation can specify that some
>entries generates an exception
It can, but why? What is to be gained? The client programmer already
knows (or can know) whether a particluar value will generate an
exception using your scheem, and therefore need not call the function to
get the exception.
If I know that the function "Sqrt( double d )" will throw an exception
if d <= 0, and I (obviously) know the value of 'd', why would I call the
function if d <= 0?
NotFound
> > > as no added value, ( except if you have specific needs regarding crashes ),
> > > neither for a user perspective or for a evelopper one.
> >
> > No added value? Is then the same that dead whitout a word?
> >
> yes
I hope don't be a user of one of yours programs.
> > Do you talk about examining a core dump of the dead program? Well, if
> > this if your system of find bugs, then a exception certainly does not
> > help.
> you have a debugger you know , and core file are really usefull sometime
Yeah, but is not the unique technique in the universe.
And a program is not forever in debugging state.
Edwin Robert Tisdale
> Again, pedantic. I could just as easily reword that to
> "Exception handling is about predictable but unexpected events
> which the programmer cannot practically prevent."
> You cannot have an expectation of something happening
> that you have no prediction of happening.
The problem is that the difference between expected and predicted
is too subtle for you to distinguish. I recommend a quick trip
to your favorite dictionary.
Edwin Robert Tisdale
> First you say there's no practical way to handle it,
> then you give a way to handle it.
You are confusing the application programmer with the library developer.
The library developer cannot handle programming errors (bugs)
made by the application programmer.
The application programmers must fix their own bugs.
Application programmers won't include code to check error codes returned
or catch exceptions throw because they passed an invalid parameter.
If the expected invalid parameters, they would include code to check them
before they passed them to the library function.
> There's no law that says that
> you can't leave checks for that sort of thing in.
No. But, once you have finished testing and debugging,
the code that checks for programming errors is unnecessary overhead.
It will be useless to the application user who isn't generally a programmer.
If you don't care about performance and efficiency, you can leave it in.
But it should come out if you do care about code speed and size.
NotFound
> >> to ensure that the parameters passed into a function are valid according
> >> to the documentation of that function. If they are not, then the
> >> function cannot guarantee *any* result, much less a properly thrown
> >> exception.
> >According to the documentation. That documentation can specify that some
> >entries generates an exception
> It can, but why? What is to be gained? The client programmer already
> knows (or can know) whether a particluar value will generate an
> exception using your scheem, and therefore need not call the function to
> get the exception.
The client can have no idea if the value is valid or not. For example,
the client can ask the user for a date and have not a calendar to chech
if it is a valid date or not. Should it have it? After all, the function
called know it and there is no need to repeat such knowledge. If the
function that does something with the date is called from multiple
programs this schema has more sense.
> If I know that the function "Sqrt( double d )" will throw an exception
> if d <= 0, and I (obviously) know the value of 'd', why would I call the
> function if d <= 0?
But if you do the function f that is sqrt (d - something), where
"something" is a private member of the class (being f a member function
of certain class) ? The class can have a function isValidArgumentToF
(double d), but in this case we have:
if (obj.isValidArgumentToF (d) ) {
obj.f (d);
...
}
else
something
And i doubt this is more clear or more effective than use exceptions.
Regards.
Daniel T.
>> >> Yes, as a matter of fact I do. It is the calling code's responsibility
>> >> to ensure that the parameters passed into a function are valid according
>> >> to the documentation of that function. If they are not, then the
>> >> function cannot guarantee *any* result, much less a properly thrown
>> >> exception.
>> >According to the documentation. That documentation can specify that some
>> >entries generates an exception
>> It can, but why? What is to be gained? The client programmer already
>> knows (or can know) whether a particluar value will generate an
>> exception using your scheem, and therefore need not call the function to
>> get the exception.
>
>The client can have no idea if the value is valid or not. For example,
>the client can ask the user for a date and have not a calendar to chech
>if it is a valid date or not. Should it have it?
Should a date that doesn't exists be allow to be created in the first
place? Maybe a better example is in order...
>> If I know that the function "Sqrt( double d )" will throw an exception
>> if d <= 0, and I (obviously) know the value of 'd', why would I call the
>> function if d <= 0?
>
>But if you do the function f that is sqrt (d - something), where
>"something" is a private member of the class (being f a member function
>of certain class) ?
OK, better example. Here we have a situation where the client using 'f'
cannot know if the parameter for the 'sqrt' function is valid, but then
the client using 'f' doesn't necessarily know that 'sqrt' is being
called (the client of 'f' should not depend on any particluar
implementation of 'f'.) The object that 'f' is being called on knows if
the parameter to 'sqrt' is valid or not and should not call 'sqrt' if
the parameter is invalid. If that means the 'f' cannot do its assigned
job (which is by no means guaranteed) then it should throw an exception
(as I said earlier,) but that has nothing to do with the 'sqrt' function.
So in your example, even if 'sqrt' threw an exception, one would not
want it propegating outside of 'f' and so one is not gaining anything by
using exceptions in this way.
Homer Meyer
> jeffc wrote:
<SNIP>
> > There's no law that says that
> > you can't leave checks for that sort of thing in.
>
> No. But, once you have finished testing and debugging,
> the code that checks for programming errors is unnecessary overhead.
> It will be useless to the application user who isn't generally a
programmer.
> If you don't care about performance and efficiency, you can leave it in.
> But it should come out if you do care about code speed and size.
Libraries should at least have asserts for that kind of thing that can be
enabled in a debugging version of the library. This helps the application
programmer find bugs in his code, and since the checks wouldn't be compiled
into the release version of the library, they would not affect performance
or efficiency.
Bob Bell
> > >Do you mean to imply that if the parameters are invalid, exceptions should
> not
> > >be thrown?
> >
> > Yes, as a matter of fact I do. It is the calling code's responsibility
> > to ensure that the parameters passed into a function are valid according
> > to the documentation of that function. If they are not, then the
> > function cannot guarantee *any* result, much less a properly thrown
> > exception.
>
> That is *precisely* the reason for using exceptions - the function cannot
> guarantee any result (that it was asked for.)
If it is throwing an exception, it is guaranteeing a result.
If it cannot guarante a result, it cannot guarantee to throw an exception.
> > ... (For example, if a function accepts a pointer to an int
> > as a parameter, can the function gracefully handle a situation where the
> > pointer points to an invalid block of memory?)
>
> Certainly.
Please explain how. There is no standard way to do this.
Bob Bell
Edwin Robert Tisdale
> Libraries should at least have asserts for that kind of thing
> that can be enabled in a debugging version of the library.
> This helps the application programmer find bugs in his code
> and, since the checks wouldn't be compiled into the release version of the
library,
> they would not affect performance or efficiency.
Yes but the standard C preprocessor macro assert isn't much help
because it can't tell the application programmer where the library function
was called
in the application program. For a better solution, see my previous
contribution
to this thread.
Kaz Kylheku
>"Kaz Kylheku" <k...@accton.shaw.ca> wrote in message
>news:KkD78.23794$Jq.11...@news2.calgary.shaw.ca...
>> Suppose that function A calls function B, which calls function C.
>> Suppose that C throws an error, but B knows how to continue working
>> after such an error. In C++ exception handling, this means that B has to
>> catch that error and continue working. But doing so hides the error from
>> because B is a subcontractor working for A, and it's taking important
>> decisions which affect A into its own hands, so to speak.
>
>What is so hard about B handling the exception and then rethrowing it to A?
What is so hard to understand about ``B continues working''?
If B rethrows, it blows itself away. Its local variables are gone.
The responses to this have astounded me with their inability to
comprehend a simple description. It's like describing inheritance to
Fortran programmers.
Alexander Terekhov
This response astounded me with your inability to
comprehend a rather simple thing -- you could always
write your own THROW {template}function or macro,
which could invoke any number of your custom "in-place"
handlers and would NOT *necessarily* transfer control
to some "real" catch-handler (or abort()) via throwing
an exception as the standard "throw-expression" does.
Also, how about this, for example:
http://groups.google.com/groups?as_umsgid=v02110100abfa24ce31eb%40%5B198.112.74.171%5D
">Are throw/catch obsoleted by conditions in general?
>(I came in after conditions were invented.)
Yes and no. If their cost (in terms of efficiency) were
equivalent you could make a case for it, but throwing
is often more efficient than signalling a condition. In
fact, most implementations of conditions are implemented
on top of throw."
and/or this:
http://groups.google.com/groups?as_umsgid=3r0vig%24c1m%40tools.near.net
"In fact, conditions can (and often *are*) implemented
using catch and throw."
... <?>
regards,
alexander.
<Apropos *multithreaded* Lisp/conditions and throw/catch>
P.S. Kaz, are there any chances/plans that you or some
other linux*threads* developer/maintainer would address
the issue of thread-cancellation/thread-exit
(pthread_exit) and *C++*-stack-unwinding? ;-)
jeffc
Too subtle == pedantic
jeffc
By the way, I'll save you the trip to your own dictionary:
"SYNONYMS: pedantic, academic, bookish, donnish, scholastic These adjectives
mean marked by a narrow, often tiresome focus on or display of learning and
especially its trivial aspects: a pedantic writing style; an academic
insistence on precision; a bookish vocabulary; donnish refinement of speech;
scholastic and excessively subtle reasoning."
@wanadoo.fr dwarfpower
"jeffc" <sp...@not.com> a écrit dans le message de news:
t3e88.8695$X2.9...@nnrp1.uunet.ca...
the trivial aspect obviously lacked, so pedantic was by your definition
inopportune
Jason Voegele
> "jeffc" <sp...@not.com> wrote:
>
> >"Daniel T." <notda...@gte.net> wrote in message
> >> Heiko Gottschling <nos...@ottomalotto.de> wrote:
> >>
> >> >what's your general opinion about exceptions? Do you use them, and if
> >> >you don't, why not?
> >>
> >> In general, an exception should be thrown by a function when the
> >> parameters passed to it are valid but the function was still unable to
> >> do its assigned job.
> >
> >Do you mean to imply that if the parameters are invalid, exceptions should not
> >be thrown?
>
> Yes, as a matter of fact I do. It is the calling code's responsibility
> to ensure that the parameters passed into a function are valid according
> to the documentation of that function. If they are not, then the
> function cannot guarantee *any* result, much less a properly thrown
> exception.
What you're describing is more formally defined as Design by Contract.
See http://www.eiffel.com/doc/manuals/technology/contract/page.html
Jason Voegele
Daniel T.
>"Daniel T." <notda...@gte.net> wrote in message
>> It is the calling code's responsibility
>> to ensure that the parameters passed into a function are valid according
>> to the documentation of that function. If they are not, then the
>> function cannot guarantee *any* result, much less a properly thrown
>> exception.
>
>What you're describing is more formally defined as Design by Contract.
> See http://www.eiffel.com/doc/manuals/technology/contract/page.html
True. DbC is a nice formal name for a very obvious characteristic of any
function.
jeffc
news:a3rsor$5h4$1...@wanadoo.fr...
> > > > The problem is that the difference between expected and predicted
> > > > is too subtle for you to distinguish. I recommend a quick trip
> > > > to your favorite dictionary.
> > > >
> > > > http://www.bartleby.com/61/
> > >
> > > Too subtle == pedantic
> >
> > By the way, I'll save you the trip to your own dictionary:
> >
> > "SYNONYMS: pedantic, academic, bookish, donnish, scholastic These
> adjectives
> > mean marked by a narrow, often tiresome focus on or display of learning
> and
> > especially its trivial aspects: a pedantic writing style; an academic
> > insistence on precision; a bookish vocabulary; donnish refinement of
> speech;
> > scholastic and excessively subtle reasoning."
> >
> >
>
> the trivial aspect obviously lacked, so pedantic was by your definition
> inopportune
Apparently you don't understand basic English grammar (semicolons), or the
word "especially". Besides, I didn't give a definition of the word pedantic -
I listed synonyms and the meaning of them as a group. Furthermore, it is more
correct to attribute the definition, if there were one, to Edward, since it
was his dictionary reference. BTW, that dictionary defines pedantic as
"Characterized by a narrow, often ostentatious concern for book learning and
formal rules: a pedantic attention to details." Now let's stop this, it's
ridiculous.
Stephen Howe
> > Occasionally my code has ended in this clause
> > and before this I have catch handlers
> > for all the types of exception I am expecting.
>
> You are confused.
No, I am not.
> Unpredictable does not mean the same thing as unexpected.
I know that but I fail to see the applicability of what you say.
> The very fact that you include a catch(...) clause
> means that you expected other exceptions
Your talking nonsense. I put catch(...) as pure defensive programming. I had
not "expected" ( here is a case Edwin Robert Tisdale falsely predicting my
reasons) the code to ever arrive there. The fact that it did was a complete
surprise to me but it did let me know that an exception type was occuring
that did not have a prior catch handler of the right type.
Stephen Howe
Alexander Terekhov
And what exception type? Thrown at which point/why thrown?
Is your way of catch(...)-and-do-not-rethrow-no-matter-what-
exception-is-this[1]-"defensive programming" really better
than my way of *abort()/"debug()"-at-throw-point-if-no-
handler-found*-"defensive programming"? And, more
importantly, "defensive"/protecting from what?
Please explain!
regards,
alexander.
[1] Somewhat weird but sometime really useful:
/**/
try {
// "basic" or "strong"
blabla_operation();
}
catch( ... ) {
handleKnownExpectedExceptions();
}
void handleKnownExpectedExceptions()
{
try {
throw;
}
catch( const KnownExpectedException1& ex1 ) { /**/ }
catch( const KnownExpectedException2& ex2 ) { /**/ }
/**/
catch( ... ) { /* UNKNOWN/UNEXPECTED */ throw; }
}
jeffc
news:3C629CB5...@web.de...
> > Your talking nonsense. I put catch(...) as pure defensive programming. I
had
> > not "expected" ( here is a case Edwin Robert Tisdale falsely predicting my
> > reasons) the code to ever arrive there. The fact that it did was a
complete
> > surprise to me but it did let me know that an exception type was occuring
> > that did not have a prior catch handler of the right type.
>
> And what exception type? Thrown at which point/why thrown?
> Is your way of catch(...)-and-do-not-rethrow-no-matter-what-
> exception-is-this[1]-"defensive programming" really better
> than my way of *abort()/"debug()"-at-throw-point-if-no-
> handler-found*-"defensive programming"? And, more
> importantly, "defensive"/protecting from what?
>
> Please explain!
Why on earth would you assume you have a debugger when the program aborts?
Stephen Howe
No idea. Microsoft have some type of extension which allows hardware
exceptions to appear as software exceptions. So they will turn up in the
catch (...) clause unless you have the right catch type. Typically
reading/writing to memory not owned by your program can do this (in other
words a bug)
> Is your way of catch(...)-and-do-not-rethrow-no-matter-what-
> exception-is-this[1]-"defensive programming" really better
> than my way of *abort()/"debug()"-at-throw-point-if-no-
> handler-found*-"defensive programming"?
Where did I ever suggest that the former is "better" than the latter in this
thread?
> And, more importantly, "defensive"/protecting from what?
Well if I did not have a catch(...) clause, the exception would continue
until either a correct catch handler was found or the program terminates
ungracefully. Customers usually expect that in the event of an error the
program would handle it gracefully or would die gracefully.
Stephen Howe
Daniel T.
>Well if I did not have a catch(...) clause, the exception would continue
>until either a correct catch handler was found or the program terminates
>ungracefully. Customers usually expect that in the event of an error the
>program would handle it gracefully or would die gracefully.
How can you die gracefully when you don't know what went wrong?
NotFound
You can free allocated resources, delete temporary files...
Regards.
Daniel T.
>> How can you die gracefully when you don't know what went wrong?
>
>You can free allocated resources, delete temporary files...
How do you know the resources need to be freed? You are in a catch (...)
block which means something happened somewhere and you don't know what
or where...
Kaz Kylheku
By the time control gets to the catch handler, unwinding has taken place.
The destructors of all automatically allocated objects within the dynamic
context of the try block have been run.