kanze@gabi-soft.de (James Kanze) wrote
> In languages of the Pascal family (e.g. Ada), you cannot
> ignore a return code;

Sure you can.

    Ignoreme := OpenFile("Filename",1)
    Ignoreme := WriteFile("Hello there!",1)
    Ignoreme := CloseFile(1)

You must assign the return code to some variable. There's nothing
requiring you to use that return code in logic.

---
[ 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                       ]

shannon.barber@myrealbox.com (Shannon Barber) wrote in message news:<de001473.0212221957.2307fd2d@posting.google.com>...
> rmaddox@isicns.com (Randy Maddox) wrote
> >
>
> There's tons of useful things an exception framework could do.
[snip]
>
> It ought to be a compilation error if the function can violate it's
> exception specification.
[snip]

For a full discussion paper, see
http://ww.andrewmarlow.co.uk/publications.html

When this was last discussed to death on c.l.c++.m, the conclusion was
that although it is desirable to fix something that is undoubtedly
broken, there seems to be no agreement on what to do about making it
work in the presence of templates.

Regards,

apm

---
[ 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                       ]

comp.std.c++_2002-12-23@nmhq.net (Niklas Matthies) writes:

> On 2002-12-23 14:36, David Abrahams <dave@boost-consulting.com> wrote:
>> shannon.barber@myrealbox.com (Shannon Barber) writes:
> [...]
>>>  - for example if you could automated building a stack-trace
>>> including both the call-chain and variable state.
>>
>> Wow, like in Python?  It sure would be nice to be able to get all of
>> that information, but it would completely screw up the C++ EH model,
>> (goodbye RAII!), not to mention that it would have a huge
>> implementation cost.
>
> I'm curious, how would building a stack trace completely screw up the
> C++ EH model and invalidate RAII?

Well, if it's to have anything to do with EH, it means the trace has
to be available after some unwinding has occurred (otherwise, why not
just replace "throw x;" with "buildstacktrace(); throw x;"?).

So how useful is that "variable state" going to be if all the
automatics have been destroyed during unwinding?

Obviously, you have to keep them alive somehow.  That's the antithesis
of RAII.

--
                       David Abrahams
   dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

---
[ 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                       ]

rmaddox@isicns.com (Randy Maddox) wrote
>
> Hear, hear!  Instead of trying to fix up exception specifications by
> making the mess even worse, just get rid of them altogether.  Has
> anyone actually found a good use for any exception specification other
> than throw()?  If not, maybe we could keep that to indicate code that
> will not throw an exception and bag the rest.  What do you think?

There's tons of useful things an exception framework could do.  The
current C++ one just doesn't do any of them.  Should the current C++
exception specification be shot? Yes.  Should they be completely
abandoned? I don't think so (and I'm not even a proponent for using
the buggers).

It ought to be a compilation error if the function can violate it's
exception specification.

Exceptions could be quite useful if they actually did something - for
example if you could automated building a stack-trace including both
the call-chain and variable state.

Right now, about all you can do with C++ exceptions is pretend you're
not using an alter'enabled goto.  There's gotta be something better
they can do than that.

---
[ 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                       ]

shannon.barber@myrealbox.com (Shannon Barber) writes:

> rmaddox@isicns.com (Randy Maddox) wrote
>>
>> Hear, hear!  Instead of trying to fix up exception specifications by
>> making the mess even worse, just get rid of them altogether.  Has
>> anyone actually found a good use for any exception specification other
>> than throw()?  If not, maybe we could keep that to indicate code that
>> will not throw an exception and bag the rest.  What do you think?
>
> There's tons of useful things an exception framework could do.  The
> current C++ one just doesn't do any of them.

Hmm, it's been *quite* useful in my work.

> It ought to be a compilation error if the function can violate it's
> exception specification.

Highly debatable.  There are certainly lots of counterarguments to
that which have never been satisfactorily answered.

> Exceptions could be quite useful if they actually did something

Really, exceptions do something.  I've seen it firsthand.  Try it
yourself (I presume you have a C++ compiler)!

>  - for example if you could automated building a stack-trace
> including both the call-chain and variable state.

Wow, like in Python?  It sure would be nice to be able to get all of
that information, but it would completely screw up the C++ EH model,
(goodbye RAII!), not to mention that it would have a huge
implementation cost.

> Right now, about all you can do with C++ exceptions is pretend you're
> not using an alter'enabled goto.  There's gotta be something better
> they can do than that.

That's a completely unsupportable claim.  Is this a troll?

--
                       David Abrahams
   dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

---
[ 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                       ]

On 2002-12-23 14:36, David Abrahams <dave@boost-consulting.com> wrote:
> shannon.barber@myrealbox.com (Shannon Barber) writes:
[...]
>>  - for example if you could automated building a stack-trace
>> including both the call-chain and variable state.
>
> Wow, like in Python?  It sure would be nice to be able to get all of
> that information, but it would completely screw up the C++ EH model,
> (goodbye RAII!), not to mention that it would have a huge
> implementation cost.

I'm curious, how would building a stack trace completely screw up the
C++ EH model and invalidate RAII?

-- Niklas Matthies

---
[ 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                       ]

shannon.barber@myrealbox.com (Shannon Barber) wrote in message news:<de001473.0212221957.2307fd2d@posting.google.com>...
> rmaddox@isicns.com (Randy Maddox) wrote
> >
> > Hear, hear!  Instead of trying to fix up exception specifications by
> > making the mess even worse, just get rid of them altogether.  Has
> > anyone actually found a good use for any exception specification other
> > than throw()?  If not, maybe we could keep that to indicate code that
> > will not throw an exception and bag the rest.  What do you think?
>
> There's tons of useful things an exception framework could do.  The
> current C++ one just doesn't do any of them.  Should the current C++
> exception specification be shot? Yes.  Should they be completely
> abandoned? I don't think so (and I'm not even a proponent for using
> the buggers).
>
> It ought to be a compilation error if the function can violate it's
> exception specification.

It would be a nice trick if the compiler could do this, and would
certainly make exception specifications more useful IMHO.

>
> Exceptions could be quite useful if they actually did something - for
> example if you could automated building a stack-trace including both
> the call-chain and variable state.
>
> Right now, about all you can do with C++ exceptions is pretend you're
> not using an alter'enabled goto.  There's gotta be something better
> they can do than that.
>

I think you mistake me here for an anti-exception person.  If so, you
are most definitely NOT correct.  Exceptions are great!  :-)  Much
more difficult to ignore than an error return code.  And much cleaner
separation of happy path and error handling code, along with compiler
dispatching to an appropriate handler.  What more could you ask for?

Exception specifications, as currently provided by C++, are a whole
'nother kettle of fish, IMHO.  They are not enforced at compile time,
which would make them more useful.  The exception is that the empty
throw() specification is quite useful to let callers know that code
will not throw any exception.  Other than that I do believe that we
could easily bag the rest of exception specifications and live quite
happily.

Randy.

---
[ 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                       ]

rmaddox@isicns.com (Randy Maddox) wrote in message
news:<8c8b368d.0212231033.20e6e02c@posting.google.com>...
> shannon.barber@myrealbox.com (Shannon Barber) wrote in message
> news:<de001473.0212221957.2307fd2d@posting.google.com>...
> > rmaddox@isicns.com (Randy Maddox) wrote

> > > Hear, hear!  Instead of trying to fix up exception specifications
> > > by making the mess even worse, just get rid of them altogether.
> > > Has anyone actually found a good use for any exception
> > > specification other than throw()?  If not, maybe we could keep
> > > that to indicate code that will not throw an exception and bag the
> > > rest.  What do you think?

> > There's tons of useful things an exception framework could do.  The
> > current C++ one just doesn't do any of them.  Should the current C++
> > exception specification be shot? Yes.  Should they be completely
> > abandoned? I don't think so (and I'm not even a proponent for using
> > the buggers).

> > It ought to be a compilation error if the function can violate it's
> > exception specification.

> It would be a nice trick if the compiler could do this, and would
> certainly make exception specifications more useful IMHO.

It would be no problem for the compiler -- Java does it for a certain
category of exceptions, and Modula-3 does it for all exceptions.

In the end, I think it depends on what exceptions are used for.  Are
they used to report exceptional cases, which can typically only be
handled far from the call site (like out of memory conditions), or are
they the one and only error reporting mechanism.  In the first case, for
everything but the simplest leaf functions (and special functions
designed to make exception safety possible -- Dave Abrahams can tell you
a lot more about this), the exception specification will not be empty.
And what good does it do you having to write "throw( std::bad_alloc )",
or even "throw( std::exception )" on every function (above a certain
basic level) you write?

If exceptions are used as the universal error reporting mechanism, of
course, the problem is different: it IS worth being able to say, for
example, that open may fail, and that the error should be handled.
Traditionally, however, the C family has not required this: before
exceptions (and even now, in C and C++), open reports errors by means of
a return code.  In languages of the Pascal family (e.g. Ada), you cannot
ignore a return code; for diverse historical reasons, in C and C++, you
can, and practically speaking, wrong or right, there is no way that this
can be changed.  (Why Java, with its supposed emphisis on safety, allows
ignoring return values, is beyond me.  Probably because the emphisis on
safety is only supposed.)

Different languages have made different choices in this regard.
Modula-3, for example, does require full statically checked exception
specifications.  This works well in Modula-3, because it uses exceptions
as the general error reporting mechanism, and really exceptional
conditions, like out of memory, are handled separately.  Java is
schizophrenic: it divides exceptions into two groups, one of which is
checked, and the other not.  Some of the unchecked exceptions are so
exceptional as to be impossible to handle, and may appear
asynchronously, which, of course, makes any pretence of exception safety
just that: a pretence.  (An obvious correlary is that it is impossible
to write a correct program in Java.)  On the other hand, other
exceptions are just everyday error conditions, which are probably better
handled by return codes (that cannot be ignored).

(Before anyone rushes to point it out, I am aware that this
categorization is a radical simplification of the real situation, and
that there is an enormous gray area where it isn't always clear whether
the error is an exceptional condition, or something to be expected.)

> > Exceptions could be quite useful if they actually did something -
> > for example if you could automated building a stack-trace including
> > both the call-chain and variable state.

> > Right now, about all you can do with C++ exceptions is pretend
> > you're not using an alter'enabled goto.  There's gotta be something
> > better they can do than that.

Exceptions ARE just dressed up goto's.  So is a return statement, or for
that matter, while and for.  Like while and for, what is important about
exceptions (in this respect) isn't what they do, but what they cannot
do; an exception can only bring you back to a catch block associated
with a try block where you've been.  It does break the rules of
structured programming.  I generally don't like it.  But if I'm going to
recover from an out of memory condition, the alternative of testing for
null after each memory allocation, and propagating the return code up,
is probably worse.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

Greetings,

Randy Maddox wrote:
> hyrosen@mail.com (Hyman Rosen) wrote in message news:<m_wL9.31157$4W1.10614@nwrddc02.gnilink.net>...

> Hear, hear!  Instead of trying to fix up exception specifications by
> making the mess even worse, just get rid of them altogether.  Has
> anyone actually found a good use for any exception specification other
> than throw()?  If not, maybe we could keep that to indicate code that
> will not throw an exception and bag the rest.  What do you think?

You might want to look at a humble proposal of mine, here:

  http://members.xoom.virgilio.it/dbolcioni/exception-specifications-1.html

which basically extends exception specifications allowing stuff like

   void f(params) throw(spec) catch(spec);

where the catch(spec) defines what the function is not supposed to
throw - i.e. the compiler must complain if the listed exceptions can
leak. My original intent with this was catching the use of functions
which cannot appear in a Unix signal handler, and it probably shows.

Davide Bolcioni
--
There is no place like /home.

---
[ 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                       ]

nid_oizo@yahoo.com_removethe_ (Nicolas Fleury) wrote in message news:<heSL9.25789$gK1.379152@wagner.videotron.net>...
> Allan W wrote:
> > Nicolas Fleury wrote:
> >
> >>Yes, it's the same thing.  The only difference is documentation.
> >
> >
> > Ah, well then, you're using the wrong keyword. You're using throw(),
> > while you should be using //throw(). The only difference is that
> > it comes AFTER the semicolen, like this:
>
> I was talking about the difference between throw(...) and
> throw(some_exception, ...), not between throw(...) and // throw(...).
> throw(some_exception, ...) would not be synonym of a comment, it would
> be synonym of throw(...) with a comment.

But throw(...) is already the default, so essentially it is a comment.

> >     void f(); //throw(...)
> >     void g(); //throw(some_exception, ...)
> >
> > This is a standard (2.7/1) feature of C++, and as far as I know ALL
> > C++ compilers support it.
>
> :)
> That's something sad with C++ exception specifications.  Despite their
> syntax that suggest they specify was exceptions can be thrown, they are
> actually used to specify what exceptions cannot be thrown.

Why is this sad?   :-(

---
[ 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                       ]

Allan W wrote:
>
> But throw(...) is already the default, so essentially it is a comment.

No, throw(...) doesn`t exist and my suggestion was not to make it a
comment, but something that enforce at compilation that calling
functions have a compatible specification or catch(...).

>>That's something sad with C++ exception specifications.  Despite their
>>syntax that suggest they specify was exceptions can be thrown, they are
>>actually used to specify what exceptions cannot be thrown.
>
>
> Why is this sad?   :-(

Java exception specifications are far more useful because of the
interesting compile-time support that ensure exceptions are caught or
specified.  I think it would be also more intuitive if no exception
specifications would mean no exception.  I'm not saying we can change
that, and I think it's sad that we just can't.

Think about it, instead of saying "I can only throw that and it is
ensured at compilation" C++ exception specifications are saying "If I
throw anything else than that, I'll call x function at run-time".

The only solution I see would be to have a new keyword to throw (raise)
and a new keyword for exception specifications (throws), and after
deprecate old style throwing.  Better forget it...

Deprecating exception specifications other than throw() like some have
suggested in this thread would be also interesting.  You can re-added
them 5 years later with only a new keyword to throw and we have useful
exception specifications by 2015 ;)

Nicolas Fleury

---
[ 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 everyone,

Do you think it would be a good idea to have partial exception
specifications in C++ (I don't know if it has a name)?

void f() throw(...);  // same as void f(); but explicit
void g() throw(some_exception, ...);  // can throw at least
                                       // some_exception
template <typename T>
void h(T t) throw(std::invalid_argument, ...);

Right now, templated code can almost only use the throw() specification,
since unknown exceptions can easily be thrown.  Correct me if I'm wrong,
but the STL has no exception specification other than throw().  Partial
exception specification could make exception specification more
documentary and provide some additional checking at compile-time a la Java.

void f() throw(...);
void g() throw(some_exception)
{
    f();
    if (x) throw some_exception();
}
// Doesn't compile, f() explicitly specified it can throw,
// exception specifcation must have ...

I'm afraid compile-time check could only be applied to cases with
specifications with "..." to be backward compatible, but I think it
would still deserve a look.

Regards,

Nicolas Fleury

---
[ 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                       ]

nid_oizo@yahoo.com_removethe_ (Nicolas Fleury) writes:

> Hi everyone,
>
> Do you think it would be a good idea to have partial exception
> specifications in C++ (I don't know if it has a name)?

This question has been hashed to death in this newsgroup and
comp.lang.c++.moderated in recent years. May I suggest a google
search?

--
                       David Abrahams
   dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

---
[ 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                       ]

Nicolas Fleury wrote:
> Do you think it would be a good idea to have partial exception
> specifications in C++ (I don't know if it has a name)?

No. It's not even a good idea to have what we have now.
It needs to be shot, not gussied up.

---
[ 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                       ]

Nicolas Fleury wrote:
> Hi everyone,
>
> Do you think it would be a good idea to have partial exception
> specifications in C++ (I don't know if it has a name)?
>
> void f() throw(...);  // same as void f(); but explicit
> void g() throw(some_exception, ...);  // can throw at least
>                                       // some_exception
> template <typename T>
> void h(T t) throw(std::invalid_argument, ...);

I don't know; what are you suggesting that it should mean? The thing
that seems most obvious is that it could throw the listed types, and
anything else? How is this different from throw(...)? It has precisely
the same list of allowed and prohibited types (all, and none, respectively).

> Right now, templated code can almost only use the throw() specification,
> since unknown exceptions can easily be thrown.  Correct me if I'm wrong,
> but the STL has no exception specification other than throw().  ...

std::allocator<T>::allocate() throws bad_alloc.
std::basic_string<> throws out_of_range and length_error all over the place.
std::locale<> throws runtime_error and bad_cast
std::vector<>::reserve() throws length_error
std::bitset<> throws out_of_range and overflow_error

Also, several functions are explicitly allowed to let escape any
exceptions created by user-defined defined functions that they call.

> ...  Partial
> exception specification could make exception specification more
> documentary and provide some additional checking at compile-time a la Java.
>
> void f() throw(...);
> void g() throw(some_exception)
> {
>    f();
>    if (x) throw some_exception();
> }
> // Doesn't compile, f() explicitly specified it can throw,
> // exception specifcation must have ...

I'm not sure exactly what you're suggesting here. Currently, section
15.4p10 says "An implementation shall not reject an expression merely
because when executed it throws or might throw an exception that the
containing function does not allow."

Currently, it's not legal for a compiler to reject that code for that
reason. What are you suggesting should be changed?

---
[ 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                       ]

James Kuyper Jr. wrote:
> Nicolas Fleury wrote:
>
>> Hi everyone,
>>
>> Do you think it would be a good idea to have partial exception
>> specifications in C++ (I don't know if it has a name)?
>>
>> void f() throw(...);  // same as void f(); but explicit
>> void g() throw(some_exception, ...);  // can throw at least
>>                                       // some_exception
>> template <typename T>
>> void h(T t) throw(std::invalid_argument, ...);
>
>
> I don't know; what are you suggesting that it should mean? The thing
> that seems most obvious is that it could throw the listed types, and
> anything else? How is this different from throw(...)? It has precisely
> the same list of allowed and prohibited types (all, and none,
> respectively).

Yes, it's the same thing.  The only difference is documentation.

>> Right now, templated code can almost only use the throw()
>> specification, since unknown exceptions can easily be thrown.  Correct
>> me if I'm wrong, but the STL has no exception specification other than
>> throw().  ...
>
>
> std::allocator<T>::allocate() throws bad_alloc.
> std::basic_string<> throws out_of_range and length_error all over the
> place.
> std::locale<> throws runtime_error and bad_cast
> std::vector<>::reserve() throws length_error
> std::bitset<> throws out_of_range and overflow_error
>
> Also, several functions are explicitly allowed to let escape any
> exceptions created by user-defined defined functions that they call.
>
>> ...  Partial exception specification could make exception
>> specification more documentary and provide some additional checking at
>> compile-time a la Java.
>>
>> void f() throw(...);
>> void g() throw(some_exception)
>> {
>>    f();
>>    if (x) throw some_exception();
>> }
>> // Doesn't compile, f() explicitly specified it can throw,
>> // exception specifcation must have ...
>
>
> I'm not sure exactly what you're suggesting here. Currently, section
> 15.4p10 says "An implementation shall not reject an expression merely
> because when executed it throws or might throw an exception that the
> containing function does not allow."
>
> Currently, it's not legal for a compiler to reject that code for that
> reason. What are you suggesting should be changed?

In that case, it was an addition.  If a function explicitly specify it
can throw anything, calling functions must either catch or have an
exception specification.  But the more I think about it, the less it
makes sense, since the compile-time checking would be too much
incomplete.  It's sad, but I guess C++ will never have exception
specifications as useful as in Java, unless using a new keyword for
throwing and for specifications...

I will follow David Abrahams suggestion and search more google history...

Regards,

Nicolas

---
[ 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                       ]

hyrosen@mail.com (Hyman Rosen) wrote in message news:<m_wL9.31157$4W1.10614@nwrddc02.gnilink.net>...
> Nicolas Fleury wrote:
> > Do you think it would be a good idea to have partial exception
> > specifications in C++ (I don't know if it has a name)?
>
> No. It's not even a good idea to have what we have now.
> It needs to be shot, not gussied up.
>

Hear, hear!  Instead of trying to fix up exception specifications by
making the mess even worse, just get rid of them altogether.  Has
anyone actually found a good use for any exception specification other
than throw()?  If not, maybe we could keep that to indicate code that
will not throw an exception and bag the rest.  What do you think?

Randy.

---
[ 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                       ]

> > Nicolas Fleury wrote:
> >> void h(T t) throw(std::invalid_argument, ...);

> James Kuyper Jr. wrote:
> > I don't know; what are you suggesting that it should mean? The thing
> > that seems most obvious is that it could throw the listed types, and
> > anything else? How is this different from throw(...)? It has precisely
> > the same list of allowed and prohibited types (all, and none,
> > respectively).

nid_oizo@yahoo.com_removethe_ (Nicolas Fleury) wrote
> Yes, it's the same thing.  The only difference is documentation.

Ah, well then, you're using the wrong keyword. You're using throw(),
while you should be using //throw(). The only difference is that
it comes AFTER the semicolen, like this:

    void f(); //throw(...)
    void g(); //throw(some_exception, ...)

This is a standard (2.7/1) feature of C++, and as far as I know ALL
C++ compilers support it.

---
[ 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                       ]

Allan W wrote:
> Nicolas Fleury wrote:
>
>>Yes, it's the same thing.  The only difference is documentation.
>
>
> Ah, well then, you're using the wrong keyword. You're using throw(),
> while you should be using //throw(). The only difference is that
> it comes AFTER the semicolen, like this:

I was talking about the difference between throw(...) and
throw(some_exception, ...), not between throw(...) and // throw(...).
throw(some_exception, ...) would not be synonym of a comment, it would
be synonym of throw(...) with a comment.

>     void f(); //throw(...)
>     void g(); //throw(some_exception, ...)
>
> This is a standard (2.7/1) feature of C++, and as far as I know ALL
> C++ compilers support it.

:)
That's something sad with C++ exception specifications.  Despite their
syntax that suggest they specify was exceptions can be thrown, they are
actually used to specify what exceptions cannot be thrown.

Regards,

Nicolas

---
[ 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                       ]