Chite Kre wrote:
>
> Attila.Feher@lmf.ericsson.se (Attila Feher) wrote in message news:<3D732285.D139FECF@lmf.ericsson.se>...
> >
> > And what would that add to our toolkit?  I mean this is a throw-away
> > throw specification (pun intended).  The function can throw anything.
> > Why not just put a comment there?
> >
> > A
> >
> Some naive reasons:
> 1. The usual run-time check of making the function a "bullet-proof"
>    one, in that no other exception can escape a throw (A, B) style
>    function can be done away with in a throw (A, B, ...) style. If
>    somebody still wants that kind of termination guarantee, one can
>    still use the throw (A, B) style.

And what does it tell?  I mean to the _compiler_, because users can read
comments as well.  I tell you what it tells to me:

I am a throw specification.  I allow type A and B thrown, or _any_
other.  So I am a throw specification with no effect whatsoever.  So I
am not a throw specification, because a throw specification has an
effect by its definition and purpose.

Let's see Herb's ES Syntax:

void f() // throw (A, B, ...)
  // gear up for As and Bs but I might throw more
{
  // uses a third party library that throw's C's

}

God!  It already supports your language feature!  And it has _exactly_
the same effect!

> 2. Interface documentation: This is what I consider a selling point.

I don't.  It will not sell a language feature.  Not to mention that it
is confusing and... well we rarely put active elements into code for
documentation purposes.

>    While developing C++ interfaces, there is a popular(?) urge to omit
>    exception specifications as it is considered to bring "unexpected()"
>    (pun-intended) behaviour that one is not prepared for.

Well, not in Herb's code. :-)  They are there, sitting in a comment.  So
documentation purpose is done, unwanted sudden crashes are avoided.

>    If the library uses a LibException base class for all its
>    exceptions (that does _not_ inherit from std::exception), then
>    many functions should have a throw (LibException, std::exception)
>    as some function that calls ::new or manipulates containers from
>    the std library might throw a std::bad_alloc.

OK.  Still: you either do define what exceptions can leave or it is not
telling _anything_ to the compiler.

> 3. A comment, IMHO, is not part of the language contract.

OK.  You have a new store, they have a service to deliver stuff to your
house.  You like the idea, because so far you had to wear that special
helmet when going shopping, so that you can still read the newsgroups;
but it was pretty uncomfortable in the Californian summer. :-)  So you
wnat make a contract with the guy and he shows it to you.  It says:

I hereby promise to you to deliver you for lunch a 2 course or a 3
course meal or something else every day.

Would you sing this contract?  My point is: your code is
_documentation_, not necessarily part of the langauge since it has
absolutely no effect.  And it isn't a contract either: it should have
promised something to be a contract.  It does not promise anything. :-(

So what I would do if I were you is to put a little contributive work
into DoxyGen, so that it can handle Herb Style Exceptions
Specifications, probably with your extension:

void f() //! \throw (A, B, ...)

Would "translate " to:

Function f is known to throw A and B and may throw other exceptions
thrown by the elements unknown in <projectname>

You could keep the syntax fully Herb Style (simpe single line comment)
but that would require more changes to DoxyGen.

Attila

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

petebecker@acm.org (Pete Becker) wrote in message
> In other words, someone who doesn't read the documentation but reads the
> header files might be able to make a better guess at what the function
> does.
>
Hmmm, IMHO, no documentation of a C++ library can claim to
document (for want of a better word :-) the library if it
(the documentation) does not include signatures (actual or
expository) of the collaborating classes' methods. To be
useful, it must tell more, but nothing can make a programmer
feel more at home than code.

So, I would say the documentation would only reinforce
the user's expectations and usually it is just the signature
that one tends to visit after having abstracted (internalised?)
the library to get the syntax correct.

namespace lib1 {
  class ex {};
  void f() throw (ex);
  // ...
}

void lib1::f()
  throw (lib1::ex)
{
  // ...
}

namespace lib2 {
  class ex {};
  void f() throw (ex);
  // ...
}
void lib2::f()
  throw (lib2::ex)
{
  // ...
}
bool use_lib1 = true | false;

#include <stdexcept>
#include <string>
void f_wrapper(int i)
  // throw (lib1::ex, lib2::ex, std::bad_alloc, std::out_of_range)
  // excep-spec getting too long and difficult to maintain, omit it? :-(
  // or, say throw (...) and point to documentation
  // or, better?, say throw (lib1::ex, lib2::ex, ...)
{
  char *p = new char[i];
  if (use_lib1) {
    lib1::f();
  } else {
    lib2::f();
  }
  std::string s;
  // ...
  s.at(i);
  s += p; // oops: can throw length_error and our code aborts at runtime
          // though the user is prepared to "handle" all exceptions
  // p saved and will be deleted later
}

void user()
{
  try {
    f_wrapper(10000);
  } catch (...) {
  }
}

This feature (already exists but has no syntax :-() does not
help in static checking in any way, allows the user a chance
to partially specify exceptions and let others pass unhindered.
No unexpected behaviour.

Regards
Chite

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Chite Kre wrote:
>
> The ..., of course, leaves a lot untold. But, at least, you are warned.

In other words, someone who doesn't read the documentation but reads the
header files might be able to make a better guess at what the function
does.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Chite Kre wrote:
>
> Hi
>
> Another item to the C++0x wish list:
>
> Allow throw (...) in an exception specification to mean "can throw
> any exception" explicitly.
>
> I believe this one along with the normal exception specification
> can help in multi-layered exception handling.
>
> class A {};
> class B {};
> class C {};
>
> void f() throw (A, B, ...)
>   // gear up for As and Bs but I might throw more
> {
>   // uses a third party library that throw's C's
>
> }

And what would that add to our toolkit?  I mean this is a throw-away
throw specification (pun intended).  The function can throw anything.
Why not just put a comment there?

A

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Attila.Feher@lmf.ericsson.se (Attila Feher) wrote in message news:<3D732285.D139FECF@lmf.ericsson.se>...
>
> And what would that add to our toolkit?  I mean this is a throw-away
> throw specification (pun intended).  The function can throw anything.
> Why not just put a comment there?
>
> A
>
Some naive reasons:
1. The usual run-time check of making the function a "bullet-proof"
   one, in that no other exception can escape a throw (A, B) style
   function can be done away with in a throw (A, B, ...) style. If
   somebody still wants that kind of termination guarantee, one can
   still use the throw (A, B) style.
2. Interface documentation: This is what I consider a selling point.
   While developing C++ interfaces, there is a popular(?) urge to omit
   exception specifications as it is considered to bring "unexpected()"
   (pun-intended) behaviour that one is not prepared for. (May be that
   is why it is called unexpected? :-)
   If the library uses a LibException base class for all its
   exceptions (that does _not_ inherit from std::exception), then
   many functions should have a throw (LibException, std::exception)
   as some function that calls ::new or manipulates containers from
   the std library might throw a std::bad_alloc.
3. A comment, IMHO, is not part of the language contract.

Don't throw this away, yet! :-)
Regards
Chite

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Chite Kre wrote:
>
> 1. The usual run-time check of making the function a "bullet-proof"
>    one, in that no other exception can escape a throw (A, B) style
>    function can be done away with in a throw (A, B, ...) style. If
>    somebody still wants that kind of termination guarantee, one can
>    still use the throw (A, B) style.

How would you decide whether to use throw(A,B,...) or to use no throw
specification at all, since they both would mean the same thing to the
compiler?

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

petebecker@acm.org (Pete Becker) wrote in message news:<3D764D2A.FCB31A3D@acm.org>...
> How would you decide whether to use throw(A,B,...) or to use no throw
> specification at all, since they both would mean the same thing to the
> compiler?
>
> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)
>
That's a good question.
Yes, to the compiler both would mean the same, and the compiler can
treat a function/pointer-to-function with a throw (...) specification
the same way it treats a function without any exception specification.
i.e., the throw (...) clause will have the same semantics as no throw
clause at all, i.e., there will be no runtime checks.

As the author of a library or more specifically some function, I have
(almost) complete control over (and knowledge? about) what functions I
call and what kinds of exception guarantees they provide. So I can decide
which exceptions I can handle and which ones I will let propagate.
So I can decide:
1. not to have a throw clause at all, which does not tell the user
   of the library much
2. have a throw (A,B) clause, by which I guarantee that I if I throw it
   will be nothing but (some-kind-of) an A or a B, and nothing else.
   (I might call unexpected() though :-(, either std::unexpected() or
   the user's own)
3. have a throw (A,B,...) by which I tell that "I am sure that the code
   might let an A or B escape (i.e., at the time I write the class
   interface :-() but I guess that it might throw more (which the user
   might have (knowledge about and/or) control over)."

The ..., of course, leaves a lot untold. But, at least, you are warned.
Regards
Chite

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi

Another item to the C++0x wish list:

Allow throw (...) in an exception specification to mean "can throw
any exception" explicitly.

I believe this one along with the normal exception specification
can help in multi-layered exception handling.

class A {};
class B {};
class C {};

void f() throw (A, B, ...)
  // gear up for As and Bs but I might throw more
{
  // uses a third party library that throw's C's

}

void g() // throw (...) (optional)
{
  try {
    f();
  } catch (A) {
    handle_an_A();
  } catch (B) {
    handle_a_B();
  }
  // no exception, normal return, or another exception, propagate
}

void h()
{
  try {
    g();
  } catch (C) {
    handle_a_C();
  } catch (...) {
    // no clue as to what it is here
    // give up and start afresh
  }
}

C could be std::bad_alloc, for example.

This is, IMHO, better than the std::bad_exception in the sense that
an original exception can be caught on an outer handler. I've
no experience with implementing exception handling (as opposed to
using it :-), and I do not know if this is feasible at all.

Regards
Chite

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]