::std sometimes needed, sometimes not

[Buster Copley]

Re: ::std sometimes needed, sometimes not

Jerry Coffin wrote:[color=blue]
> In article <jrv9b.4832$UN4 .245@newsread3. news.pas.earthl ink.net>,
> usenet1.spamfre e.fusion@neverb ox.com says...
>
> [ commenting on a quote from James Kanze ... ]
>
>[color=green]
>>This sounds like someone who doesn't understand exceptions to me.[/color]
>
>
> Others would disagree. Just for example, Herb Sutter (author of
> Exceptional C++, More Exceptional C++ and an upcoming and TTBOMK, as yet
> unnamed book on exceptions) lists James Kanze as "guru" here:
>
> http://www.gotw.ca/gotw/056.htm
>
> [ ... ]
>
>[color=green]
>>Reference? Without reading the opposing argument, I'm very likely to
>>side with Stroustrup over some generic, unnamed "experts".[/color]
>
>
> I'm not sure of the arguments in question either, but if James Kanze is
> among those making the argument, I'd guess that at the very least, it's
> worth studying in detail. Herb Sutter isn't the only one who names or
> acknowledges him either -- he is, for example, listed in the
> acknowledgement s of a number of books I have handy, including (for one
> example) _C++ In a Nutshell_, from O'Reilly and Associates (who
> generally aren't disposed toward publishing really bad books anyway).
>[/color]

Heh heh. So am I, but I hope no one thinks I'm an expert.
Regards,
Buster.

[Kevin Goodsell]

Re: ::std sometimes needed, sometimes not

Jerry Coffin wrote:
[color=blue]
>
> A contrast violation means there is something wrong with the code (i.e.
> a bug) that has been found and noted, and needs to be fixed.[/color]

For the record, I wasn't really considering the context of the quoted
message, just exception handling in general.

Now, if you were to use exception handling, and base your exceptions off
the standard exceptions, a contract violation would be considered a
std::logic_erro r. There are other types of exceptions that you might use
that would not be the result of a contract violation.

But looking at just the contract violation case, obviously it's a bug
that should be fixed. But at least some bugs always make it into the
final product. Terminating the program when a problem is found is not a
very useful behavior from the perspective of the user of the
application. In fact, I don't think most users would be very happy with
that.
[color=blue]
>
> In this case, aborting is a LONG ways from being the worst case. Quite
> the contrary: the worst case is that the problem is allowed to continue
> unnoticed for some arbitrary period of time[/color]

Yes, I agree that this is bad. But it only happens if you explicitly
ignore the exception.
[color=blue]
> -- almost inevitably, the
> longer a bug persists, the more difficult and expensive it is to fix.
> Therefore, when you DO find what you're sure is a bug in some code, the
> best case is to ensure that it fails as quickly, dependably and
> spectacularly as possible, so it will be fixed as soon as possible
> instead of being allowed to persist.[/color]

This is not true from the user's perspective, though.
[color=blue]
>
> The problem with throwing an exception in a case like this is that it's
> all too easy (and common) for somebody to do something like this:
>
> int main(int argc, char **argv) {
> do {
> try {
> return real_main(argc, char **argv);
> }
> catch(...) {
> std::cerr<<"Som e problem -- retrying\n";
> }
> } while(1);
> return 0; // never really executes
> }
>
> In fact, almost any instance of "catch(...) " can cover up an almost
> arbitrary collection of problems that the library designer is TRYING to
> make sure get noticed.[/color]

Yes, I definitely agree that this is a problem. But one way to look at
it is that it's not really *your* problem. If you threw the exception,
you've done your part. If the caller ignores it, then they screwed up.
But this doesn't make any difference in many cases. If the program
breaks for the customer, you'll still be in trouble.

So I see the point, but I don't think aborting is an ideal solution, in
particular once the program is in the customer's hands. An exception
could be an ideal solution, if it's not ignored. As far as I know,
there's no way to be sure of this.

A few ideas come to mind, but none is anywhere near perfect. You could
abort or throw depending on a build setting, for example. But if you
test with abort and ship with throw then you don't even know if the
catching code is in place or doing anything sensible. You'd have to test
with throw, and it could be covered up.

You could try to make an un-ignorable exception, maybe. Suppose your
exception object includes a 'handled' flag. On construction, this flag
is false. The catcher must set it to true. On destruction, if the flag
does not indicate that the exception was handled, the destructor aborts
the program. The problem is that it can still be ignored, it just takes
a little more effort (catch, set the flag, do nothing else).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Mike Wahler]

Re: ::std sometimes needed, sometimes not


Marcin Vorbrodt <mvorbro@eos.nc su.edu> wrote in message
news:bk5m5s$t1e $1@uni00nw.unit y.ncsu.edu...[color=blue]
> Hi there. How come when in one file i unclude <cmath> i need to use
> std::tan(...), and in another file i include <cassert> and std::assert[/color]
fails[color=blue]
> to compile. Nowhere in my code i do using namespace std; Seams like some
> things in my header files are in std namespace and some are not.[/color]

Exactly. Macros are not ('assert' is a macro) in a namespace.
They cannot be, since they're merely text substitutions.
[color=blue]
> Is that
> correct, or is my compiler (mingw, 3.2 i think) horribly broken? :o)[/color]

It's fine.

-MIke

[llewelly]

Re: ::std sometimes needed, sometimes not

Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> writes:
[color=blue]
> llewelly wrote:
>[color=green]
> > Before you write code signaling a programmer error with an
> > exception,
> > read this thread on assert versus exceptions:
> > http://groups.google.com/groups?thre...ing.google.com
> > or:
> > http://tinyurl.com/nhp7[/color]
>
> I don't know if you were talking specifically about the particular
> message that link goes to, but I don't think I could disagree more
> with this point:[/color]

That's exactly the point I was referring to.
[color=blue]
>
>

> - You definitely do NOT want to throw an exception in case of a
> contract violation. It is very, very rare, if ever, that this is
> correct. The program is incorrect, and you abort.
>
> The fact that every function can potentially throw an exception
> makes writing exception safe code pratically impossible.
>
> A lot of people seem to want exceptions anyway:-). To keep them
> happy, I would suggest some sort of callback, which the user can
> replace. By default, the code should abort. If the user replaces
> it with something which will throw, his code probably will not work
> when the exception occurs. But since that's what he wanted...
>

>
> This sounds like someone who doesn't understand exceptions to me.
>[color=green]
> >[color=darkred]
> >>Stroustrup has an
> >>example of this somewhere, IIRC. Probably in "The C++ Programming
> >>Language".[/color]
> > [snip]
> > He does. However, other experts have since argued that is generally
> > bad advice.[/color]
>
> Reference? Without reading the opposing argument, I'm very likely to
> side with Stroustrup over some generic, unnamed "experts".[/color]

Here's David Abrahams, with a similar opinion:

http://www.boost.org/more/error_handling.html

As for 'unnamed experts', I felt it was obvious that the name of the
expert I was referring to was James Kanze. I won't claim his
opinions should always take precedence over Stroustrup's, but
IMO, James's posts show plenty of wisdom, experience, and
insight. (With some errors here and there. :-) You should google
for his posts, and read a few to form your own opinion.

Finally, you could email Stroustrup for his current opinion on
whether exceptions should be used to signal programmer
errors. Maybe it has changed.

[llewelly]

Re: ::std sometimes needed, sometimes not

Gianni Mariani <gi2nospam@mari ani.ws> writes:
[color=blue]
> Kevin Goodsell wrote:[color=green]
> > llewelly wrote:[/color]
>
> ..
>[color=green]
> >

> > - You definitely do NOT want to throw an exception in case of a
> > contract violation. It is very, very rare, if ever, that this is
> > correct. The program is incorrect, and you abort.
> > The fact that every function can potentially throw an exception
> > makes writing exception safe code pratically impossible.
> > A lot of people seem to want exceptions anyway:-). To keep
> > them
> > happy, I would suggest some sort of callback, which the user can
> > replace. By default, the code should abort. If the user replaces
> > it with something which will throw, his code probably will not work
> > when the exception occurs. But since that's what he wanted...
> >

> > This sounds like someone who doesn't understand exceptions to me.
> >[/color]
>
> OK - time for some friendly debate.
>
> I'll state that I use exceptions very rarely and hardly ever in
> production code.
>
> I actually agree the the quote 100% because I have done exactly that
> and found that it is a very acceptable paradigm for developing solid
> and easily maintainable code.
>
> I have found that exceptions leed to sloppy code by less experienced
> programmers and even some more experienced guys as well.[/color]
[color=blue]
>
> However, I'm open to suggestions. I'm only 90% conviced they're next
> to useless.[/color]
[snip]

Hm. Maybe it isn't clear from this snippet, but from what I know,
James isn't conviced exceptions are useless. He just thinks they
should be used for conditions one plans on responding to, and
*not* for programmer errors. If you read further into the
referenced thread, you'll see more.

[Marcin Vorbrodt]

Re: ::std sometimes needed, sometimes not

"Mike Wahler" <mkwahler@mkwah ler.net> wrote in message
news:tFJ9b.5419 $UN4.143@newsre ad3.news.pas.ea rthlink.net...
[color=blue]
>
> Marcin Vorbrodt <mvorbro@eos.nc su.edu> wrote in message
> news:bk5m5s$t1e $1@uni00nw.unit y.ncsu.edu...[color=green]
> > Hi there. How come when in one file i unclude <cmath> i need to use
> > std::tan(...), and in another file i include <cassert> and std::assert[/color]
> fails[color=green]
> > to compile. Nowhere in my code i do using namespace std; Seams like some
> > things in my header files are in std namespace and some are not.[/color]
>
> Exactly. Macros are not ('assert' is a macro) in a namespace.
> They cannot be, since they're merely text substitutions.
>[color=green]
> > Is that
> > correct, or is my compiler (mingw, 3.2 i think) horribly broken? :o)[/color]
>
> It's fine.
>
> -MIke
>[/color]

Thanks a lot! Makes sense.

Martin.
[color=blue]
>
>[/color]

[llewelly]

Re: ::std sometimes needed, sometimes not

Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> writes:
[color=blue]
> Gianni Mariani wrote:[color=green]
> > Kevin Goodsell wrote:[color=darkred]
> >>
> >>

> >> - You definitely do NOT want to throw an exception in case of a
> >> contract violation. It is very, very rare, if ever, that this is
> >> correct. The program is incorrect, and you abort.
> >>
> >> The fact that every function can potentially throw an exception
> >> makes writing exception safe code pratically impossible.
> >>
> >> A lot of people seem to want exceptions anyway:-). To keep them
> >> happy, I would suggest some sort of callback, which the user can
> >> replace. By default, the code should abort. If the user replaces
> >> it with something which will throw, his code probably will not work
> >> when the exception occurs. But since that's what he wanted...
> >>

> >>
> >> This sounds like someone who doesn't understand exceptions to me.
> >>[/color]
> > OK - time for some friendly debate.
> > I'll state that I use exceptions very rarely and hardly ever in
> > production code.
> > I actually agree the the quote 100% because I have done exactly that
> > and found that it is a very acceptable paradigm for developing solid
> > and easily maintainable code.[/color]
>
> I don't think that library code should ever unilaterally abort the
> program. Besides that, doing so causes objects to go undestructed,
> leading to resource leaks (sure, most modern desktop systems clean up
> when the process terminates, but you can't count on that in portable
> code).
>
> I don't understand why you would prefer aborting to throwing an
> exception anyway. What's the worst case for throwing an exception?
> It's not caught, and the program aborts. So by aborting instead of
> throwing, you're ensuring that you always get the worst case.[/color]
[snip]

A contract violation occurs when a programmer has made an error
in the design or implementation of the code. So the violation
proves the code is incorrect in some unknown manner. Throwing an
exception results in the execution of cleanup code. However, the
code is known to be incorrect, but the nature of the error isn't
known precisely, so one can't know if it is safe to execute the
cleanup code; there may be some device-controlling object whose
destructor is supposed to shutdown the device, but misbehaves
terribly if the object is overwritten by e.g. memcpy with wrong
parameters. Terminating is not necessarily the worst case when
throwing an exception. Thus the abort.

There's also a conceptual mismatch. Exceptions have acompanying
features - try, catch(), destructors, - for responding to the
exception, and carrying on with the program's job. However, if
the code is wrong, the proper response is to fix the code. How do
you put that in your catch block? In general, I don't think you
can, especially not in a language like C++ .

There's an exception safety issue. Any useful level of exception
safety must rely on a few non-throwing operations. Yet in
principle a programmer error can occur in any aperation. Few
people put asserts in every function, but there are no-throw
functions complex enough to need asserts. If you try agressively
to detect programmer errors, and throw exceptions when programmer
errors are detected, I think you'll find it much more difficult,
to make your code exception safe.

Finally, there's an environment support issue. On many
implementations , throwing an exception unwinds the stack,
destroying any informantion about where the error was
detected. Typically, no stack trace is printed when the program
terminate()s due to an uncaught exception. By contrast, abort()
often leaves a core image behind, which can be loaded into a
debugger and inspected.

This isn't an argument for never using exceptions; I believe
exceptions are for conditions the code 'understands', and is
designed to repsond to. abort() is for conditions that can only
occur if some programmer has written incorrect code.

[Jerry Coffin]

Re: ::std sometimes needed, sometimes not

In article <bk731j$de3$1@n ews7.svr.pol.co .uk>, buster@none.com says...

[ ... ]
[color=blue]
> Heh heh. So am I, but I hope no one thinks I'm an expert.[/color]

No insult intended, but thinking about it a moment, that particular book
probably was a bad choice, and I apologize for mentioning it -- not
because I think it's a bad book, but the way in which I mentioned it
could (easily) be seen as self-serving, which I honestly didn't intend.

That aside, I think James Kanze is a respectable (and respected) C++
programmer with a tremendous amount of knowledge; while he's human, and
therefore may be wrong at times, dismissing his opinion without careful
consideration is usually a serious mistake, at least IMO.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Gavin Deane]

Re: ::std sometimes needed, sometimes not

Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> wrote in message news:<yUI9b.599 0$BS5.2284@news read4.news.pas. earthlink.net>. ..[color=blue]
> A few ideas come to mind, but none is anywhere near perfect. You could
> abort or throw depending on a build setting, for example. But if you
> test with abort and ship with throw then you don't even know if the
> catching code is in place or doing anything sensible. You'd have to test
> with throw, and it could be covered up.[/color]

That's exactly what I do and I don't see any problem. I am working on
small scale stuff though, with a build time measaured in a few minutes
at most, not several hours. It is very easy for me to do a release
build during testing to check that the catching code does what it is
supposed to (which isn't much - write the error message to a file and
exit the program).

GJD

[Jerry Coffin]

Re: ::std sometimes needed, sometimes not

In article <yUI9b.5990$BS5 .2284@newsread4 .news.pas.earth link.net>,
usenet1.spamfre e.fusion@neverb ox.com says...

[ ... ]
[color=blue]
> For the record, I wasn't really considering the context of the quoted
> message, just exception handling in general.[/color]

That explains a LOT. I certainly don't think James meant that comment
in general (i.e. that you should all exceptions would be better off as
abort()'s).

[ ... ]
[color=blue]
> But looking at just the contract violation case, obviously it's a bug
> that should be fixed. But at least some bugs always make it into the
> final product. Terminating the program when a problem is found is not a
> very useful behavior from the perspective of the user of the
> application. In fact, I don't think most users would be very happy with
> that.[/color]

I quite agree, and James basically allowed for the same possibility:
handle the situation with a call-back function. The default call-back
abort()'s, but the user of the class can register a different one that
does what he deems appropriate -- probably throw some exception.

[ ... ]
[color=blue]
> Yes, I agree that this is bad. But it only happens if you explicitly
> ignore the exception.[/color]

Yes, but explicitly ignoring the exception (or handling it
inappropriately , if it inherits from an inappropriate base) is often
very easy to do.
[color=blue][color=green]
> > -- almost inevitably, the
> > longer a bug persists, the more difficult and expensive it is to fix.
> > Therefore, when you DO find what you're sure is a bug in some code, the
> > best case is to ensure that it fails as quickly, dependably and
> > spectacularly as possible, so it will be fixed as soon as possible
> > instead of being allowed to persist.[/color]
>
> This is not true from the user's perspective, though.[/color]

That depends on the user and the type of code involved. It's also
possible to install a default handler that attempts to sit in the middle
ground. Just for example, quite a few recent MS programs have a handler
that asks to email a bug report to them if an exception percolates out
far enough. Offhand, I don't know that they're using C++ exceptions for
this (it wouldn't surprise me if they use their own Structured Exception
Handling instead) but the idea is more or less independent of the
implementation.
[color=blue]
> Yes, I definitely agree that this is a problem. But one way to look at
> it is that it's not really *your* problem. If you threw the exception,
> you've done your part. If the caller ignores it, then they screwed up.
> But this doesn't make any difference in many cases. If the program
> breaks for the customer, you'll still be in trouble.[/color]

The point is that you really haven't "done your part." Exceptions are
intended to handle situations that are (or at least may be) recoverable.
Just for example, if a memory allocation fails, a program might attempt
to free up other memory that's caching various data, and then continue
with its job. Therefore, an exception works well.

Unless you have a system in which it at least MIGHT be possible to
recover from a contract violation, an exception is not an appropriate
way of dealing with the problem (an example would be if the program
responded to a contract violation by attempting to download an updated
version of the component that caused the problem).

[ ... ]
[color=blue]
> You could try to make an un-ignorable exception, maybe. Suppose your
> exception object includes a 'handled' flag. On construction, this flag
> is false. The catcher must set it to true. On destruction, if the flag
> does not indicate that the exception was handled, the destructor aborts
> the program. The problem is that it can still be ignored, it just takes
> a little more effort (catch, set the flag, do nothing else).[/color]

I think we're mostly in agreement here -- ultimately, C++ doesn't
provide a single, obvious way that a contract violation _should_ always
be handled. I'm reasonably convinced that the usual exception mechanism
without any adornment (for lack of a better word) is rarely a good way
to handle it. The adornment you've given above might work nicely for
some situations, but I'm not at all sure that it's a universal solution
either.

That's not intended as a slam though: it may easily be that there simply
IS no universal solution to this problem, or at least that if there is
it's not a direct, simple and obvious one.

--
Later,
Jerry.

The universe is a figment of its own imagination.