In article <3b587ab3.1280252@news.cis.dfn.de>, Matthias Benkmann
<mbenkmann@gmx.de> writes
>How does an empty exception specification allow the compiler to do
>optimizations?
> If I understand correctly, for a function with empty throw
>specification, a compliant compiler has to create code that checks for
>an unexpected exception and code to throw std::unexpected

No, it calls std::unexpected() which is a call back. Nothing is allowed
to get past an empty throw spec. If you violate one about all you can do
is to close down the program.  This is important because the compiler
knows that it is not required to make any preparation for an exception
propagating from this function call.  Yes, it has to check that the spec
is not violated but when it traps a violation that is it, there is
nothing the program can do to continue (well you might try something
deeply nasty such as raising a signal :(


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

I'll pose the counter argument for exception specifications -

Exception specifications provide runtime assurance that the specified
exceptions (or no exceptions) will be thrown from a function.

If the exception specification specifies no exceptions then the compiler can
further optimize the code since it doesn't need to worry about the stack
unwinding at that call site.

If an exception specification is violated - the default behavior (if
std::bad_exception isn't specified) is to terminate the application. That
makes the guarantee quite a bit stronger than a comment or documentation and
limits the scope of exception handling required by each user of the system.

Having dealt with both static exception specifications and C++ runtime
specifications I can say there are tradeoffs. Personally, I would prefer
static checking with a simple notation for strengthening an exception
specification to get the compiler to take it - but as is, runtime exception
specifications are far better than no exception specifications.

As an example of what I'd like:

void foo() throw(); // Foo doesn't throw.
void bar() throw(std::bad_allocation); // bar only throws a bad allocation

void test() throw(int)
    {
    foo();          // allowed
    bar() throw();  // allowed* - specification may be strengthened at call
    bar();          // not allowed, statically violates specification
    bar() throw(int); // not allowed, cannot weaken or change specification
    }


* This should be equivalent to:

try
    {
    bar();
    }
catch (std::bad_allocation)
    {
    std::unexpected();  // Doesn't return
    }

That is - I'd like to see the runtime behavior moved to the call site, and
the specifications to be statically checked.

Sean

in article nDG47.34396$wr.185359@news1.frmt1.sfba.home.com, Tzvetan Mikov at
ceco@jupiter.com wrote on 7/16/01 12:00 PM:

>
> Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
> news:KbOnqoBxJ4T7Ews4@ntlworld.com...
>> In article <r8I37.32267$wr.154555@news1.frmt1.sfba.home.com>, Tzvetan
>> Mikov <ceco@jupiter.com> writes
>>> I still think that C++ exceptions in their current form are useless (see
> my
>>> other post for details) and if I am wrong I will appreciate examples of
> why.
>>
>> Exceptions are indispensable (how else do you propose to deal with ctor
>> failures?) but that is not to say that exception specifications are
>> helpful.
>
> I am sorry, of course I meant "C++ exception specifications in their current
> form are useless". I hope that is also implied from the rest of my post.
> Still, by the fact that nobody has commented negatively on my claim, I
> assume that this is mostly agreed on.
>
> So, is there any hope for improvement on this in C++0x?
>
> -tzvetan
>
>
> ---
> [ 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.research.att.com/~austern/csc/faq.html                ]
>

--
Sean Parent
Sr. Engineering Manager
Adobe Workgroup Services
sparent@adobe.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.research.att.com/~austern/csc/faq.html                ]

> If the exception specification specifies no exceptions then the compiler can
> further optimize the code since it doesn't need to worry about the stack
> unwinding at that call site.

Which means that the only useful exception specification is the empty
one.  The rest suffer from the general lameness without giving any
performance benefit.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Ron Natalie" <ron@sensor.com> wrote in message
news:3B560A57.59F0416A@sensor.com...
> Which means that the only useful exception specification is the empty
> one.  The rest suffer from the general lameness without giving any
> performance benefit.

Visual C++, an otherwise not very standard compliant compiler :-), seems to
do the reasonable thing in this case: it ignores all exception
specifications except the empty one which enables it to do significant
optimizations.

I've been thinking about developing a "static exception checker", perhaps
using the GCC front-end. I am not sure how well it could handle STL
however - static exception checking and templates don't seem to mix very
well. May be that's the reason why there's no static checking in the
language?

-tzvetan


---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Thu, 19 Jul 2001 17:10:55 GMT, "Tzvetan Mikov" <mikov@prodigy.net>
wrote:

>
>"Ron Natalie" <ron@sensor.com> wrote in message
>news:3B560A57.59F0416A@sensor.com...
>> Which means that the only useful exception specification is the empty
>> one.  The rest suffer from the general lameness without giving any
>> performance benefit.
>
>Visual C++, an otherwise not very standard compliant compiler :-), seems to
>do the reasonable thing in this case: it ignores all exception
>specifications except the empty one which enables it to do significant
>optimizations.

How does an empty exception specification allow the compiler to do
optimizations?
 If I understand correctly, for a function with empty throw
specification, a compliant compiler has to create code that checks for
an unexpected exception and code to throw std::unexpected in that case
(unless of course it can prove that no exception can occur, in which
case the optimization can always be done even without exception
specification).

MSB

----
By the way:
Vacuum cleaners suck!

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Michiel Salters <Michiel.Salters@cmg.nl> wrote in message
news:uZB27.13766$Kf3.148228@www.newsranger.com...
>
> For an organization with good practices, the problems you sketch
> aren't fatal. And you omit an important part: the comparison with
> other methods. Where's the typesafety in setting errno/
> returning NULL/calling abort() ?

I think Andrei was more likely comparing to Java's static exception safety -
the code simply does not compile if it doesn't handle all declared
exceptions or throws an undeclared one. The C++ exception specification in
comparison has always struck me as practically useless - in order to verify
that exception specifications aren't violated I must construct tests
throwing all possible exceptions in all possible contexts - that is absurd!
The runtime overhead makes it undesirable even for documentation purposes.

-tzvetan



---
[ 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.research.att.com/~austern/csc/faq.html                ]

Tzvetan Mikov wrote:

>
> Michiel Salters <Michiel.Salters@cmg.nl> wrote in message
> news:uZB27.13766$Kf3.148228@www.newsranger.com...
>>
>> For an organization with good practices, the problems you sketch
>> aren't fatal. And you omit an important part: the comparison with
>> other methods. Where's the typesafety in setting errno/
>> returning NULL/calling abort() ?
>
> I think Andrei was more likely comparing to Java's static exception safety
> - the code simply does not compile if it doesn't handle all declared
> exceptions or throws an undeclared one. The C++ exception specification in
> comparison has always struck me as practically useless - in order to
> verify that exception specifications aren't violated I must construct
> tests throwing all possible exceptions in all possible contexts - that is
> absurd! The runtime overhead makes it undesirable even for documentation
> purposes.

Can't you just specify throw() and thus know for sure that there is no
throw?

if you use something that forgets to do so, you can simply
catch(...)...
I don't see what's unpractical in here..

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3B4B7F40.7E22B8E4@animats.com>, John Nagle says...
>
>Michiel Salters wrote:
>>
>> In article <l.994654755.1525543212@1cust227.tnt48.nyc3.da.uu.net>,
>> u448791503@spawnkill.ip-mobilphone.net says...
>> >
>> >Hi everybody
>> >
>> >does anyone else think that current semi-run-time exception
>> >specification approach makes usage of exception handling
>> >practically useless and even harmful?
>>
>> Yes. But I don't.
>>
>> >speaking formally static type safety is only thing which we
>> >can rely on when we put different tested separetly modules
>> >together.
>
>     Personally, coming from a proof of correctness background,
>I'd be very happy to have entry conditions, exit conditions, and
>object invariants built into the language.  Then you could clearly
>specify, and check, what requirements a function puts on its caller.
>But I realize that level of rigor is not going to happen in C++.  My
>"strict C++" proposal isn't nearly that strict.
>
>     John Nagle
>     Animats
>

Even entry checks and exit conditions don't give perfect guarantees;
the compiler can't prove (in general) that the postcondition of step
1 is a perfect subset of the precondition of step 2. But as I've said
in my original response (in other words), perfect isn't a requirement.
99% safety often is good enough - for a first step.

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Tzvetan Mikov wrote:
>
> Michiel Salters <Michiel.Salters@cmg.nl> wrote in message
> news:uZB27.13766$Kf3.148228@www.newsranger.com...
> >
> > For an organization with good practices, the problems you sketch
> > aren't fatal. And you omit an important part: the comparison with
> > other methods. Where's the typesafety in setting errno/
> > returning NULL/calling abort() ?
>
> I think Andrei was more likely comparing to Java's static exception safety -
> the code simply does not compile if it doesn't handle all declared
> exceptions or throws an undeclared one.

Unless, of course, the exception is derived from RuntimeException --
they're unchecked, and some Java programmers recommend using unchecked
exceptions rather than jumping through the hoops required by checked
exceptions.

--
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.research.att.com/~austern/csc/faq.html                ]

Eyal Lotem <eyal@hyperroll.com> wrote in message
news:3b4ed19c@news.bezeqint.net...
>
> Can't you just specify throw() and thus know for sure that there is no
> throw?

Of course not. If I specify throw() that means that I hope that there are no
uncaught throws in the function, but I can't be certain unless I:
 a) personally inspect the source or
 b) I run the function under all possible circumstances to make sure it
actually doesn't throw.

If I am going to do a) then how is the exception specification different
from just a comment saying /*doesn't throw*/? I still have to manually
inspect every line of code. In many cases this could be a tremendous task
considering nested function calls, etc.

b) is just plain impossible.

Here is a short example:

void func1 ( int param );
int func ( int param ) throw (SomeException)
{
  if ((param % 12345) == 0) throw OtherException();
  func1();
  return param + 1;
}

Approach a) (manual inspection of the code) tells us that the exception
specification is violated in the beginning of the function. Further on, we
must also inspect func1() in this way since it could throw anything. The
exception specification is totally redundant since I have to go through the
code anyway.

Approach b) requires us to call func() with all numbers from INT_MIN to
INT_MAX. Perhaps this could be done but if there were two parameters we'd
better give up ... :-)

So, I don't see how exception specifications are supposed to be used. I hate
to make absolute statements like that and I will be happy to see examples
showing that exception specifications are even moderately useful in
practice.

-tzvetan

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message
news:3B4E622B.B3A75BDF@acm.org...
> Unless, of course, the exception is derived from RuntimeException --
> they're unchecked, and some Java programmers recommend using unchecked
> exceptions rather than jumping through the hoops required by checked
> exceptions.

I don't know - I haven't used a lof of Java (although obviously I've made
the effort to learn it). I think that Java's checked exceptions are very
helpful and ellegant, much more than unchecked ones, but since I haven't
used Java in real-world projects I can't really say. They must have their
reasons to use unchecked exceptions but that just shows that exception
specifications may be not very usefull in any form. Personally, I would
prefer to have static checking in C++ like in Java. "throw(...)" should be
used in the (supposedly) rare cases when unchecked exceptions are needed.

I still think that C++ exceptions in their current form are useless (see my
other post for details) and if I am wrong I will appreciate examples of why.

-tzvetan





---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <r8I37.32267$wr.154555@news1.frmt1.sfba.home.com>, Tzvetan
Mikov <ceco@jupiter.com> writes
>I still think that C++ exceptions in their current form are useless (see my
>other post for details) and if I am wrong I will appreciate examples of why.

Exceptions are indispensable (how else do you propose to deal with ctor
failures?) but that is not to say that exception specifications are
helpful.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
news:KbOnqoBxJ4T7Ews4@ntlworld.com...
> In article <r8I37.32267$wr.154555@news1.frmt1.sfba.home.com>, Tzvetan
> Mikov <ceco@jupiter.com> writes
> >I still think that C++ exceptions in their current form are useless (see
my
> >other post for details) and if I am wrong I will appreciate examples of
why.
>
> Exceptions are indispensable (how else do you propose to deal with ctor
> failures?) but that is not to say that exception specifications are
> helpful.

I am sorry, of course I meant "C++ exception specifications in their current
form are useless". I hope that is also implied from the rest of my post.
Still, by the fact that nobody has commented negatively on my claim, I
assume that this is mostly agreed on.

So, is there any hope for improvement on this in C++0x?

-tzvetan


---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <l.994654755.1525543212@1cust227.tnt48.nyc3.da.uu.net>,
u448791503@spawnkill.ip-mobilphone.net says...
>
>Hi everybody
>
>does anyone else think that current semi-run-time exception
>specification approach makes usage of exception handling
>practically useless and even harmful?

Yes. But I don't.

>speaking formally static type safety is only thing which we
>can rely on when we put different tested separetly modules
>together.

You're going to be in for a lot of surprises if you think you
can rely on typesafety. It isn't enough to know that a function takes
an int and you pass ant int. The actual restriction might be
"an int smaller than 30000", and there is no interface to
specify that to the linker.

> and current C++ exception specification doesn't fit
>here. mutliple possible practical scenarios with only control
>as run-time hooks like terminate() and unexpected() all lead
>to the idea of exception handling as something bringing more
>disadvantages than advantages for non-trivial project which
>should be done at time.

The other side of the coin is the fragileness you introduce
when you demand that modules are aware of each others exception
specifications. Imagine a call-back in a library. My library
function calls your functions/functor, and if that throws you get
the exception back. Unsafe ? No. But how can the library author
specify what he throws ? He can't, but you as caller do know what
will be thrown.

>suppose i am project lead. i have to keep telling my team: do
>not use functions and methods which can throw in your
>desctructors because if you do terminate() *may* be called and
>there is almost nothing we can do if terminate() has been
>called. the same story about unexpected(). i can hardly imagine
>what really usefull i can do in this function. so i am trying to
>avoid it by all (organizational) means: i keep saying something
>and check other's people code to be sure in something.

Well, any decent coding team will do code inspections. Throwing
dtors aren't that hard to spot. Still, if they miss it your tests
will hit a breakpoint in unexpected(), at which point breakpoints
in the expcetion ctors can take you to the point where the exception
is thrown.

>it makes me think that current model of exception handling is not
>good enough to serve practical purposes.

For an organization with good practices, the problems you sketch
aren't fatal. And you omit an important part: the comparison with
other methods. Where's the typesafety in setting errno/
returning NULL/calling abort() ?

Regards,
Michiel Salters

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Michiel Salters wrote:
>
> In article <l.994654755.1525543212@1cust227.tnt48.nyc3.da.uu.net>,
> u448791503@spawnkill.ip-mobilphone.net says...
> >
> >Hi everybody
> >
> >does anyone else think that current semi-run-time exception
> >specification approach makes usage of exception handling
> >practically useless and even harmful?
>
> Yes. But I don't.
>
> >speaking formally static type safety is only thing which we
> >can rely on when we put different tested separetly modules
> >together.

     Personally, coming from a proof of correctness background,
I'd be very happy to have entry conditions, exit conditions, and
object invariants built into the language.  Then you could clearly
specify, and check, what requirements a function puts on its caller.
But I realize that level of rigor is not going to happen in C++.  My
"strict C++" proposal isn't nearly that strict.

     John Nagle
     Animats

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hi everybody

does anyone else think that current semi-run-time exception
specification approach makes usage of exception handling
practically useless and even harmful?

speaking formally static type safety is only thing which we
can rely on when we put different tested separetly modules
together. and current C++ exception specification doesn't fit
here. mutliple possible practical scenarios with only control
as run-time hooks like terminate() and unexpected() all lead
to the idea of exception handling as something bringing more
disadvantages than advantages for non-trivial project which
should be done at time.

suppose i am project lead. i have to keep telling my team: do
not use functions and methods which can throw in your
desctructors because if you do terminate() *may* be called and
there is almost nothing we can do if terminate() has been
called. the same story about unexpected(). i can hardly imagine
what really usefull i can do in this function. so i am trying to
avoid it by all (organizational) means: i keep saying something
and check other's people code to be sure in something.

it makes me think that current model of exception handling is not
good enough to serve practical purposes.

any comments on that?

regards
Andrei Smirnov, asmirnov@asmirnov.com






--
Sent by asmirnov from asmirnov in field  com
This is a spam protected message. Please answer with reference header.
Posted via http://www.usenet-replayer.com/cgi/content/new

---
[ 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.research.att.com/~austern/csc/faq.html                ]