Perhaps a mechanism can be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_erro r".
That is make the compiler to check exception specifications for errors too.
Ioannis A. Vranos 12 2762
In article <fm***********@ ulysses.noc.ntu a.gr>, iv*****@no.spam freemail.nospam .gr says...
Perhaps a mechanism can be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
[ ... ]
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_erro r".
That is make the compiler to check exception specifications for errors too.
This is next to impossible in practice. In particular, the compiler
doesn't have anything to check against with externally defined functions
-- i.e. you include a header with an exception specification, but the
compiler has no access to the implementation of the "stuff" in that
header (unless it happens to be included inline).
In practice, doing so probably wouldn't be a good idea anyway. Java has
checked exceptions, where the compiler does (more or less) what you're
advocating. Experience has shown (repeatedly) that while this seems like
a good idea, it almost never works well in practice.
In the end, exception specifications are an anti-pattern -- something
that initially seems like a good idea, but in the long run ends up
causing far more problems than it solves.
One of the basic ideas of exception handling is that it sets up more or
less a "tunnel" from the place an exception is thrown to the place it is
caught, and any intermediate layers need not worry about it (beyond
being exception safe). Exception specifications (especially enforced as
you're advocating) require that all intermediate levels DO pay attention
to the exceptions that propagate from the lower levels, though the
intermediate layer has no real interaction with the exception itself at
all. Worse, an intermediate layer might easily work with a function via
a pointer, in which case it simply has no way of knowing what exceptions
might be thrown through it by that function. You could make the
exception specification part of the function signature, so it could only
take pointers to functions that threw from a limited selection of
exceptions, but this would frequently be quite limiting. In many cases,
such call-back functions (and such) haven't even been contemplated when
the code that uses them is written, so it's essentially impossible for
them to even guess at what exceptions they might throw.
In addition, templates and exception specifications are essentially
impossible to blend. A typical template can throw most (if not all) the
exceptions that can be thrown by the type over which it is instantiated
-- but an many cases, nobody has yet imagined the type over which it
will be isntantiated when the template itself is written.
I'll repeat: exception specifications are an anti-pattern. They're
nearly always bad now, and having the compiler attempt to enforce them
would make them even worse.
--
Later,
Jerry.
The universe is a figment of its own imagination.
On 2008-01-20 18:13, Ioannis Vranos wrote:
Perhaps a mechanism can be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_erro r".
That is make the compiler to check exception specifications for errors too.
You might be interested in the following two articles (just a few among
many discussing the subject):
http://herbsutter.spac es.live.com/blog/cns!2D4327CC297 151BB!149.entry http://www.mindview.net/Etc/Discussi...ckedExceptions
--
Erik Wikström
Ioannis Vranos wrote:
Perhaps a mechanism can be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_erro r".
That is make the compiler to check exception specifications for errors too.
Some more details:
What I have in mind is "loose" application. That is, the compiler should
check only the available code accessible to it.
In addition, I think throw(void) should be equivalent to throw(), and
throw(...) should be equivalent to non-throw specification, e.g.:
// May throw anything.
void somefunc()
{
// ...
}
// May throw anything.
void some func() throw(...)
{
// ...
}
I think that even loose, the compile time checking of throw
specifications will improve the overall exception safety, and everyone
will usually know the exact types of exceptions he can catch on a given
call.
Any existing third-party, pre-built C++ library can be revised to
provide exception specifications at its next release. That is, in the
future the total exception safety will increase, because the exception
specification mechanism will finally work (since now I think it doesn't
work as it is provided, in practice).
Or that library can keep providing its facilities without exception
specifications or with the throw(...) equivalent ones.
If I may repeat, what I have in mind is "loose" application. That is,
the compiler should check only the available code accessible to it.
In the case of some function having the throw() specification, is using
indirectly code that may throw some exception, it can be flagged as a
compile-time error, provided that this source code that is used
indirectly by this function, is accessible to the compiler. Otherwise,
it will not be flagged as a compile-time error.
The run-time stuff of the throw specifications will still apply.
Ioannis Vranos wrote:
Ioannis Vranos wrote:
>Perhaps a mechanism can be introduced in the C++0x/1x standard, something simple like defining a function as:
void somefunc(void) throw() { // ... }
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification. somefunc can throw std::bad_alloc, std::range_erro r".
That is make the compiler to check exception specifications for errors too.
Some more details:
What I have in mind is "loose" application. That is, the compiler should
check only the available code accessible to it.
In addition, I think throw(void) should be equivalent to throw(), and
throw(...) should be equivalent to non-throw specification, e.g.:
// May throw anything.
void somefunc()
{
// ...
}
// May throw anything.
void some func() throw(...)
{
// ...
}
I think that even loose, the compile time checking of throw
specifications will improve the overall exception safety, and everyone
will usually know the exact types of exceptions he can catch on a given
call.
Any existing third-party, pre-built C++ library can be revised to
provide exception specifications at its next release. That is, in the
future the total exception safety will increase, because the exception
specification mechanism will finally work (since now I think it doesn't
work as it is provided, in practice).
Or that library can keep providing its facilities without exception
specifications or with the throw(...) equivalent ones.
If I may repeat, what I have in mind is "loose" application. That is,
the compiler should check only the available code accessible to it.
In the case of some function having the throw() specification, is using
indirectly code that may throw some exception, it can be flagged as a
compile-time error, provided that this source code that is used
indirectly by this function, is accessible to the compiler. Otherwise,
it will not be flagged as a compile-time error.
The run-time stuff of the throw specifications will still apply.
Addition 2:
In this proposal, I think an opposite of the throw keyword may be
needed, to specify the exceptions that the compiler will ignore. I think
the right place of it, is the end of the function scope. An example:
void somefunc() throw()
{
std::vector<int vec;
// ...
} nothrow(std::ou t_of_range)
Ioannis Vranos wrote:
Ioannis Vranos wrote:
>Ioannis Vranos wrote:
>>Perhaps a mechanism can be introduced in the C++0x/1x standard, something simple like defining a function as:
void somefunc(void) throw() { // ... }
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification. somefunc can throw std::bad_alloc, std::range_erro r".
That is make the compiler to check exception specifications for errors too.
Some more details:
What I have in mind is "loose" application. That is, the compiler should check only the available code accessible to it.
In addition, I think throw(void) should be equivalent to throw(), and throw(...) should be equivalent to non-throw specification, e.g.:
// May throw anything. void somefunc() { // ... }
// May throw anything. void some func() throw(...) { // ... }
I think that even loose, the compile time checking of throw specificatio ns will improve the overall exception safety, and everyone will usually know the exact types of exceptions he can catch on a given call.
Any existing third-party, pre-built C++ library can be revised to provide exception specifications at its next release. That is, in the future the total exception safety will increase, because the exception specificatio n mechanism will finally work (since now I think it doesn't work as it is provided, in practice).
Or that library can keep providing its facilities without exception specificatio ns or with the throw(...) equivalent ones.
If I may repeat, what I have in mind is "loose" application. That is, the compiler should check only the available code accessible to it.
In the case of some function having the throw() specification, is using indirectly code that may throw some exception, it can be flagged as a compile-time error, provided that this source code that is used indirectly by this function, is accessible to the compiler. Otherwise, it will not be flagged as a compile-time error.
The run-time stuff of the throw specifications will still apply.
Addition 2:
In this proposal, I think an opposite of the throw keyword may be
needed, to specify the exceptions that the compiler will ignore. I think
the right place of it, is the end of the function scope. An example:
void somefunc() throw()
{
std::vector<int vec;
// ...
} nothrow(std::ou t_of_range)
Some examples of these:
I.
void somefunc() throw(std::bad_ alloc, my_app::graph_r ange_error)
{
// ...
} nothrow(std::ou t_of_range)
II. Equivalent cases:
void somefunc() throw()
{
// ...
} nothrow(std::ba d_alloc)
void somefunc() throw(void)
{
// ...
} nothrow(std::ba d_alloc)
III. Equivalent cases:
void somefunc()
{
// ...
}
void somefunc() throw(...)
{
// ...
}
void somefunc() throw(...)
{
// ...
} nothrow()
void somefunc()
{
//...
} nothrow()
void somefunc() throw(...)
{
// ...
} nothrow(void)
void somefunc()
{
//...
} nothrow(void)
Ioannis Vranos wrote:
>
>>>Perhaps a mechanism can be introduced in the C++0x/1x standard, something simple like defining a function as:
void somefunc(void) throw() { // ... }
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification. somefunc can throw std::bad_alloc, std::range_erro r".
That is make the compiler to check exception specifications for errors too.
Some more details:
What I have in mind is "loose" application. That is, the compiler should check only the available code accessible to it.
In addition, I think throw(void) should be equivalent to throw(), and throw(...) should be equivalent to non-throw specification, e.g.:
// May throw anything. void somefunc() { // ... }
// May throw anything. void some func() throw(...) { // ... }
I think that even loose, the compile time checking of throw specification s will improve the overall exception safety, and everyone will usually know the exact types of exceptions he can catch on a given call.
Any existing third-party, pre-built C++ library can be revised to provide exception specifications at its next release. That is, in the future the total exception safety will increase, because the exception specification mechanism will finally work (since now I think it doesn't work as it is provided, in practice).
Or that library can keep providing its facilities without exception specification s or with the throw(...) equivalent ones.
If I may repeat, what I have in mind is "loose" application. That is, the compiler should check only the available code accessible to it.
In the case of some function having the throw() specification, is using indirectly code that may throw some exception, it can be flagged as a compile-time error, provided that this source code that is used indirectly by this function, is accessible to the compiler. Otherwise, it will not be flagged as a compile-time error.
The run-time stuff of the throw specifications will still apply.
Addition 2:
In this proposal, I think an opposite of the throw keyword may be needed, to specify the exceptions that the compiler will ignore. I think the right place of it, is the end of the function scope. An example:
void somefunc() throw() { std::vector<int vec;
// ...
} nothrow(std::ou t_of_range)
Some examples of these:
I.
void somefunc() throw(std::bad_ alloc, my_app::graph_r ange_error)
{
// ...
} nothrow(std::ou t_of_range)
II. Equivalent cases:
void somefunc() throw()
{
// ...
} nothrow(std::ba d_alloc)
void somefunc() throw(void)
{
// ...
} nothrow(std::ba d_alloc)
III. Equivalent cases:
void somefunc()
{
// ...
}
void somefunc() throw(...)
{
// ...
}
void somefunc() throw(...)
{
// ...
} nothrow()
void somefunc()
{
//...
} nothrow()
void somefunc() throw(...)
{
// ...
} nothrow(void)
void somefunc()
{
//...
} nothrow(void)
Addition 3:
IV.
// The compiler ignores all exceptions and considers that somefunc()
// will not throw any exception. Thus it will not provide a compile-time
// error.
void somefunc() throw()
{
throw std::bad_alloc( );
} nothrow(...)
"Ioannis Vranos" <iv*****@no.spa mfreemail.nospa m.grwrote in message
news:fm******** ***@ulysses.noc .ntua.gr...
Perhaps a mechanism can be introduced in the C++0x/1x standard, something
simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_erro r".
The problem with this is that *any* expression that has the capability of
causing undefined behavior has the capability of throwing any exception. In
particular, this property means that an implementation is permitted to
extend the language so that arithmetic errors, such as division by zero,
throw exceptions.
What would you have such an implementation do about an arithmetic operation
inside a throw() function that might overflow? If the compiler complains
about it, it is rejecting a program that might have nothing wrong with it.
If it doesn't, then you need to figure out how to change your requirement to
permit such behavior.
On 2008-01-20 23:46, Ioannis Vranos wrote:
Ioannis Vranos wrote:
[snip]
Could you please choose one thread for this discussion? Posting the same
thing in multiple threads makes the discussion hard to follow. And it
is a waste of bits :-)
--
Erik Wikström
Erik Wikström wrote:
On 2008-01-20 23:46, Ioannis Vranos wrote:
>Ioannis Vranos wrote:
[snip]
Could you please choose one thread for this discussion? Posting the same
thing in multiple threads makes the discussion hard to follow. And it
is a waste of bits :-)
In my newsgroup reader (Thunderbird) the message appears in the same
discussion thread, with subject "C++0x/1x exception specifications
proposal: Compile-time checked". This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: Ensoul Chee |
last post by:
I used
#include <iostream.h>
int m;
cout << "Hexadecimal == 0x" << hex << m << endl;
to print value of m in hexadecimal mode.
But I got the compile error like this
couttest.cpp:20 `hex' undeclared (first use this function)
|
by: Ioannis Vranos |
last post by:
I would like to see your views on these.
C++98 is already a large language since it supports 4 paradigms and each one
is supported well, with optimal space and time efficiency. And this is
excellent.
From the few things that i have read about C++0x, in addition to some C99...
features (actually some other term comes in my mind for this instinctively,
but it is another subject for discussion), there is library expansion with
|
by: benben |
last post by:
Why doesn't the following code work?
template <typename ExceptionT>
void f(void) throw (ExceptionT)
{
throw ExceptionT();
}
Ben
|
by: Brian |
last post by:
I'm trying to comile some managed C++ code in VC++ 2005 beta that has a lot
of exception specifications,ie
int func() throw( SomeException*) ;
I'm getting these messages:
error C2353: exception specification is not allowed.
unfortunately MSDN isn't much help here. Obviously, C++/CLI is not allowing
|
by: junw2000 |
last post by:
Is C++ Exception handling useful? think it is too complicated. What
kinds of project need to use it? Thanks.
| |
by: Sektor van Skijlen |
last post by:
Is there any official proposal for annotations in C++0x?
So far annotations have been "implicitly" used in many proposals as some
(usually) free-form text enclosed in ] (for example, n2493, n2509, n1943 -
not used in later updates). Is there any consistent proposal for the general
mechanism of annotations?
--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
|
by: LewGun |
last post by:
at the end of last year Herb Sutter told us that "C++ 0x has been
fixed", now GCC4.3 had been released, the compiler were known as "the C
++ new features' experimental unit",but it support to the new features
is very limited, what do you think about the "C++0x" and the standard
compilers will come in future?
|
by: Keith Halligan |
last post by:
I'm a bit unsure about exception specifications and the rules that
they enforce.
I've had a look at the C++ spec and it doesn't state about the errors
that it enforces, if an exception is thrown in a function that isn't
specified in its exception specification (assuming there's one
there).
If I compile the code below on Solaris, Linux and AIX, I get the
program coring, causing the "std::exception" to be thrown back to the
|
by: Dmitriy V'jukov |
last post by:
On Jun 16, 3:09 pm, Anthony Williams <anthony....@gmail.comwrote:
Yes, I've already read this. It's just GREAT! It's far more useful and
intuitive.
And it contains clear and simple binding to memory model, i.e.
relations between acquire/release fences; and between acquire/release
fences and acquire/release operations.
|
by: Dmitriy V'jukov |
last post by:
Latest C++0x draft N2723, 2008-08-25:
"1.9/7
When the processing of the abstract machine is interrupted by receipt
of a signal, the values of objects which
are neither
— of type volatile std::sig_atomic_t nor
— lock-free atomic objects (29.2)
are unspecified, and the value of any object not in either of these
two categories that is modified by the
handler becomes undefined."
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
| |
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
| |
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |