David Casperson wrote:
>
> In article <39DA67BE.BC2C99B8@wizard.net>,
> James Kuyper  <kuyper@wizard.net> wrote:
> >...In such a context,
> [using a checked access function in a context where the access parameter
>  is provably correct.]
> >using a checked access method that could in principle
> >throw that exception (but won't) is poor design. It may be poor design
> >of a class you have no access to, but it's still poor design.
>
> What about
>     switch (n)
>         {
>         default:
>             throw CantHappen() ;
>         ...
>         }
> ?
>
> Do you claim that exceptions should never be thrown to assert that the
> programmer has made an error in reasoning?  A critical part of your
> argument above seems to me to be that programmers / designers never make
> logic errors in deciding whether or not to check access.  Do you claim
> that good software engineering should take this as a tenet of faith?

No, that's not what I believe - my own design style involves making such
checks as a matter of course. However, the message I was responding to
was making just such a claim when it said the exception would never be
thrown, and I was taking that claim at face value. It's not quite as
ridiculous a claim as it seems, if taken as an approximation, rather
than literal truth. It's often the case that performance issues outweigh
reliability ones. I'm just saying that if the performance penalty of
catching the exception is unacceptable, then surely the performance
penalty of performing the check that throws it would be even worse. I'm
afraid I didn't make that point as clear as I should have.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sai Pulugurtha wrote:
>
> I beg to differ with you on this. I do not mind compiler issuing a
> diagnostic warning message(as a matter of fact it helps). But for me
> this is defenitely not an error.
>
> In my example, I have made sure that the loop can never go "out of
> range" and hence there is no need for me to deal with the exception.

In such a context, using a checked access method that could in principle
throw that exception (but won't) is poor design. It may be poor design
of a class you have no access to, but it's still poor design. I don't
think that makes it a good argument against enforcement of exception
specifications.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Sai Pulugurtha wrote:
> >
> > I beg to differ with you on this. I do not mind compiler issuing a
> > diagnostic warning message(as a matter of fact it helps). But for me
> > this is defenitely not an error.
> >
> > In my example, I have made sure that the loop can never go "out of
> > range" and hence there is no need for me to deal with the exception.
>
> In such a context, using a checked access method that could in principle
> throw that exception (but won't) is poor design. It may be poor design
> of a class you have no access to, but it's still poor design. I don't
> think that makes it a good argument against enforcement of exception
> specifications.
>

I disagree.  Exceptions and exception specifications are part of an
error handling mechanism.  If it is possible to avoid conditions
that cause a given exception to be thrown, there is a cost associated
with catching that exception (eg writing and maintaining the code
for an empty exception handler, and any clutter caused by having
lots of them) but no real benefits.

It would be sort of like a compiler forcing me to turn

    y = 2/x;

into

    if (x != 0)
       y = 2/x;

when *I* have enforced the condition that x is non-zero in a way
that's invisible to a compiler.   Very few programmers would be
happy if forced to do that, just as few programmers would be
happy forced to handle an exception they *know* can not be
thrown.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

>Sai Pulugurtha wrote:
>>
>> I beg to differ with you on this. I do not mind compiler issuing a
>> diagnostic warning message(as a matter of fact it helps). But for me
>> this is defenitely not an error.
>>
>> In my example, I have made sure that the loop can never go "out of
>> range" and hence there is no need for me to deal with the exception.
>
>In such a context, using a checked access method that could in principle
>throw that exception (but won't) is poor design.

I *completely* disagree.

It is very very VERY common for a programmer to *think* that he or she
has written code in such a way that it won't cause problems at
runtime, but for those problems to crop up anyway!  If you don't check
for them, the result will be undefined behaviour.  If you're really
*lucky*, the program will just crash.  But if you're unlucky, the
program will corrupt data somewhere else, leading to failures a long
way down the track.  These kinds of failures are invariably much more
difficult to debug.  In the worst case, corrupted data can get written
out to files, and if the error is not noticed soon enough, all the
backups can become corrupted too.  If this happens, I can guarantee
that your users will not thank you!

*If* your program is performance-sensitive (which is becoming much
less common as computers get faster), and *if* this code might be on
a critical path, then and only then should you use an unchecked access
method.  But otherwise, you should use checked access methods, since
they will catch errors sooner and thus make problems easier and
cheaper to fix.

If statically checked exception specifications meant that programmers
were encouraged to use unchecked access methods rather than checked
access methods, even in cases where performance was not an issue,
this would be a BIG step backwards.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39DA67BE.BC2C99B8@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>...In such a context,
[using a checked access function in a context where the access parameter
 is provably correct.]
>using a checked access method that could in principle
>throw that exception (but won't) is poor design. It may be poor design
>of a class you have no access to, but it's still poor design.

What about
    switch (n)
        {
        default:
            throw CantHappen() ;
        ...
        }
?

Do you claim that exceptions should never be thrown to assert that the
programmer has made an error in reasoning?  A critical part of your
argument above seems to me to be that programmers / designers never make
logic errors in deciding whether or not to check access.  Do you claim
that good software engineering should take this as a tenet of faith?

David
--
Dr. David Casperson                          |  casper@unbc.ca
Department of Mathematics & Computer Science |  (250) 960-6672
Faculty of Science                           |
College of Science and Management            |
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Robert O'Dowd wrote:
>
> James Kuyper wrote:
...
> > In such a context, using a checked access method that could in principle
> > throw that exception (but won't) is poor design. It may be poor design
> > of a class you have no access to, but it's still poor design. I don't
> > think that makes it a good argument against enforcement of exception
> > specifications.
> >
>
> I disagree.  Exceptions and exception specifications are part of an
> error handling mechanism.  If it is possible to avoid conditions
> that cause a given exception to be thrown, there is a cost associated
> with catching that exception (eg writing and maintaining the code
> for an empty exception handler, and any clutter caused by having
> lots of them) but no real benefits.

You misunderstand my comment. I'm suggesting that if you're going to
guarantee that the condition will always be avoided, and resources are
so tight that you can't afford the expense of catching the exception,
then you probably also can't afford the time wasted checking that
condition. If such use will be commonplace, then it's bad design to not
provide an unchecked access method.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I beg to differ with you on this. I do not mind compiler issuing a
diagnostic warning message(as a matter of fact it helps). But for me
this is defenitely not an error.

In my example, I have made sure that the loop can never go "out of
range" and hence there is no need for me to deal with the exception.

Thanks,
Sai Pulugurtha

In article <39D52785.75DF9C1B@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
>
> The fact that you think this should compile marks you as someone
against
> exception checking. However, I would think that it shouldn't, and I'd
> prefer it if the language had been written so that it wouldn't. I
> realize that find() has been written in such a way that g() won't
throw,
> but I don't think that the legality of the code should depend upon
such
> subtleties. If such use is going to be commonplace, an unchecked
access
> method (such as operator[]() in some of the C++ standard containers)
> should be provided. You can always add needed checking to an unchecked
> access method; you can't remove wasteful checking from a checked
access
> method.


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

in article 8qvnb4$5k1$1@nnrp1.deja.com, Sai Pulugurtha at sai_p@my-deja.com
wrote on 9/29/00 7:53 AM:

> Consider this:
>
> X get(int i) throw(out_of_range);
> int find(X& x) throw()
> {
> for (int i = 0; i < size(); ++i) {
> if (x == get(i)) return i;
> }
> return -1;
> }
>
> Should this compile? I defenitely think so. If exceptions are checked
> at compile time, this could be an error.
>
> For a more detailed discussion on this topic, check out this article
> written by Jack Reeves, that got published in C++ Report in July 1996.
>
> http://www.stat.cmu.edu/~lamj/sigs/c++-report/cppr9607.c.reeves.html
>
> Thanks,
> Sai Pulugurtha
> Brainbench MVP for C++
> http://www.brainbench.com
>
> In article <B5D9C1AA.BB60%anders@milkweed.com>,
> Anders Pytte <anders@milkweed.com> wrote:
>> Hi folks,
>>
>> Sorry to drag this up again, but a colleague asked my recently: why
> wasn't
>> compile time enforcement of exception specifications approved by the
>> standards committee.

Andrew Koenig suggested that this was a factor in the committee's decision,
although the example he gave was quite different. I think Andrew was
involved with the standards discussion at the time, so I tend to accept his
explanation, although in D&E Stroustrup cites completely different
considerations.

In your example above, one might prefer to use a no-throw version of get
(for example, std::vector has operator[]) to avoid the overhead of checking
bounds each time through the loop. In that case there would be no conflict.

Since you might have come late to the thread, allow me to forward a
solution
some suggested for the above dilemma - a compile time switch to turn of
static checking of exception specification for sections of code.

The situation is somewhat analogous to const qualification, since there are
times - hopefully rare - when the engineer knows best and overrides const
qualification. One might even provide a feature to "cast" a function's
exception specification, to no-throw, in your case.

Anders


--
Anders Pytte                                   Milkweed Software
PO Box 32                                  voice: (802) 586-2545
Craftsbury, VT 05826                  email: anders@milkweed.com


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sai Pulugurtha wrote:
>
> Consider this:
>
> X get(int i) throw(out_of_range);
> int find(X& x) throw()
> {
>   for (int i = 0; i < size(); ++i) {
>     if (x == get(i)) return i;
>   }
>   return -1;
> }
>
> Should this compile? I defenitely think so. If exceptions are checked
> at compile time, this could be an error.

The fact that you think this should compile marks you as someone against
exception checking. However, I would think that it shouldn't, and I'd
prefer it if the language had been written so that it wouldn't. I
realize that find() has been written in such a way that g() won't throw,
but I don't think that the legality of the code should depend upon such
subtleties. If such use is going to be commonplace, an unchecked access
method (such as operator[]() in some of the C++ standard containers)
should be provided. You can always add needed checking to an unchecked
access method; you can't remove wasteful checking from a checked access
method.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8qvnb4$5k1$1@nnrp1.deja.com>, Sai Pulugurtha wrote:
> X get(int i) throw(out_of_range);
> int find(X& x) throw()
> {
>   for (int i = 0; i < size(); ++i) {
>     if (x == get(i)) return i;
>   }
>   return -1;
> }
>
> Should this compile? I defenitely think so. If exceptions are checked
> at compile time, this could be an error.

I believe the whole point of this discussion is that many of us believe
that the code you have presented should *NOT* compile - or at the very
least that it should cause the compiler to emit "a diagnostic".

Under the current standard the code will compile, but if the get(i) in
your loop throws out_of_range (as it is allowed to do) the program will
detect that this exception cannot be thrown by find() and will instead
call the function std::unexpected() whose usual action is to terminate
the application immediately (with potentially disasterous results).

Cheers,
 Daniel
[nospam.demon.co.uk is a spam-magnet. Replace nospam with sonadata to
reply]




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Consider this:

X get(int i) throw(out_of_range);
int find(X& x) throw()
{
  for (int i = 0; i < size(); ++i) {
    if (x == get(i)) return i;
  }
  return -1;
}

Should this compile? I defenitely think so. If exceptions are checked
at compile time, this could be an error.

For a more detailed discussion on this topic, check out this article
written by Jack Reeves, that got published in C++ Report in July 1996.

http://www.stat.cmu.edu/~lamj/sigs/c++-report/cppr9607.c.reeves.html

Thanks,
Sai Pulugurtha
Brainbench MVP for C++
http://www.brainbench.com

In article <B5D9C1AA.BB60%anders@milkweed.com>,
  Anders Pytte <anders@milkweed.com> wrote:
> Hi folks,
>
> Sorry to drag this up again, but a colleague asked my recently: why
wasn't
> compile time enforcement of exception specifications approved by the
> standards committee.


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stephen Clamage <stephen.clamage@sun.com> writes:

> I think it is for the same reason that the compiler is not required to
> diagnose falling off the end of a function that has a non-void return
> type: In general, you cannot determine that the specification WILL be
> violated
>
> The committee considered the possibility of disallowing even the
> possibility of a violation of the exception specification, but decided
> against it as being too severe.

In my opinion, that was the right decision.  I don't think that anyone
understands very well how compile time exception specification
checking would interact with templates.  Much better not to have
compile time exception specification checking than to risk getting it
wrong.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matthew Austern wrote:
> Stephen Clamage <stephen.clamage@sun.com> writes:
> > The committee considered the possibility of disallowing even the
> > possibility of a violation of the exception specification, but decided
> > against it as being too severe.
>
> In my opinion, that was the right decision.  I don't think that anyone
> understands very well how compile time exception specification
> checking would interact with templates.  Much better not to have
> compile time exception specification checking than to risk getting it
> wrong.
>
 Well, consider the following (currently unavaliable) exception specification:
throw(?). For example:

 template <class Fun> void f(Fun fun) throw(?)
 {
  fun();
 }

 struct A {
        void operator()() throw(int) {}  // throws int
 };

 struct B {
        void operator()() throw()    {}  // doesn't throw
 };

 int main()
 {
  f(A());
  f(B());
 }

Here compiler instantiates

 void f(A fun) throw(int) { /* ... */ }

and

 void f(B fun) throw()    { /* ... */ }

respectively. That is, throw(?) construct means: deduce an actual exception
specification at compile time. And the throw(?) construct is allowed only with
templates.
--
         With all respect, Sergey.          http://cpp3.virtualave.net/
         mailto : ders at skeptik.net
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi folks,

Sorry to drag this up again, but a colleague asked my recently: why wasn't
compile time enforcement of exception specifications approved by the
standards committee.

And i realized that even after all the discussion I still did not know!

Note that this is a different question than: why is compile time enforcement
of exception specifications bad? I want to know exactly what issues the
committee based their decision on.

Many thanks,

Anders.

--
Anders Pytte                                   Milkweed Software
PO Box 32                                  voice: (802) 586-2545
Craftsbury, VT 05826                  email: anders@milkweed.com


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 10 Sep 00 05:11:09 GMT, Anders Pytte <anders@milkweed.com> wrote:

>Sorry to drag this up again, but a colleague asked my recently: why wasn't
>compile time enforcement of exception specifications approved by the
>standards committee.
>
>And i realized that even after all the discussion I still did not know!

I think it is for the same reason that the compiler is not required to
diagnose falling off the end of a function that has a non-void return
type: In general, you cannot determine that the specification WILL be
violated

The committee considered the possibility of disallowing even the
possibility of a violation of the exception specification, but decided
against it as being too severe.

A compiler can warn about cases where a function might throw a
disallowed exception, but it is not required to do so.


---
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]