Archived

This topic is now archived and is closed to further replies.

inline ... throw()

This topic is 5575 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I was browsing trough some code while I stumbled against a constructor of this form :
    
inline MyClass() throw() {
    _myVar1 = 10;
    _myVar2 = 20;
}
     
My questions are these : a) why make a constructor INLINE? b) what does the throw do? I've worked with error handling before, but here it's after my constructors declaration, haven't seen this before Greetz... [edit] source tag included [edited by - jkeppens on September 7, 2002 6:32:26 PM]

Share this post


Link to post
Share on other sites
inline constructor - useless and, IIRC illegal.
throw() - exception specification : the function never throws - compilers implement them poorly, they should be disregarded.

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

Share this post


Link to post
Share on other sites
Exceptions specifications are compiled... they just aren''t as useful as they were supposed to be, since std::unexpected() always call std::terminate().

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

Share this post


Link to post
Share on other sites
quote:
Original post by Fruny
inline constructor - useless and, IIRC illegal.


Why? Sure, you have to be careful about what you inline - and constructors can easily contain more code than you think - but other than that constructors aren't that special, are they?

According to the Standard, default constructors and implicitly generated destructors are public and inline . I'd be very surprised if user-declared inline constructors were somehow illegal.

[edited by - spock on September 8, 2002 7:08:02 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by civguy
[quote]Original post by Fruny
std::unexpected() always call std::terminate().
Huh? What about std::set_unexpected()



Doesn''t really make a lot of difference, given that:
Required behavior: An unexpected_handler shall not return. See also 15.5.2.


Whether it be by calling terminate or some other similar function, it has to end the program.

Share this post


Link to post
Share on other sites
I think that if you throw a bad_exception exception from your unexpected exception handler the program does not end because the exception can be caught, I have not tested it though; I have not been able to get my unexpected exception handler called yet, and I don´t think I will continue wasting my time trying to get it. I use visual c++6.0 and as far as I know it ignores exception specifications...

[edited by - spetznaz on September 8, 2002 1:51:46 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by DrPizza
Doesn't really make a lot of difference, given that:
Required behavior: An unexpected_handler shall not return. See also 15.5.2.

Hmm, at least according to Stroustrup, it still can *throw* stuff.

This compiled fine in Dev-C++ (mingw/gcc)

        
#include <stdlib.h>
#include <iostream>
#include <exception>
#include <string>

class E {
public:
std::string _message;
E(const std::string &message) : _message(message) {}
};

class E2 { };

void a(bool throwIllegal) throw(E) {
if (throwIllegal)
throw E2();
else
throw E("normal");
}

void myUnexpectedHandler() throw(E) {
throw E("unexpected");
}

int main(int argc, char *argv[]) {
std::set_unexpected(&myUnexpectedHandler);
try {
a(true);
} catch (E e) {
std::cout << e._message << std::endl;
}

try {
a(false);
} catch (E e) {
std::cout << e._message << std::endl;
}

system("PAUSE");
return 0;
}

And the output was
unexpected
normal

So I can't really agree with this:
quote:
Original post by DrPizza
Whether it be by calling terminate or some other similar function, it has to end the program.


[edited by - civguy on September 8, 2002 2:11:03 PM]

Share this post


Link to post
Share on other sites
MSVC (I know, I know...) discards exceptions specifications and never calls unexpected(). Only terminate().

But then, nobody said VC++ was standard-compliant. It is however, unfortunately widespread.

Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
it is not a good thing for a constructor to throw exceptions because of resource (memory) leaks. See "Effective C++" and "More effective C++"

Share this post


Link to post
Share on other sites
RAII is useless without that strategy, and "Exceptional C++" by Sutter contradicts what you just said.

(Dueling references? [theme from deliverance])

[edited by - Stoffel on September 9, 2002 12:47:00 PM]

Share this post


Link to post
Share on other sites
Empty exception specifications (e.g. "MyClass() throw()") mean that the method will never throw an exception. These are recognised by VC. It can do some small optimizations since it knows it doesn''t have to do anything to worry about an exception from that call.

Full exception specifications where you say what types of exceptions can be thrown aren''t supported, or at least not well, as others have said.

-Mike

Share this post


Link to post
Share on other sites
quote:
Original post by siaspete
[quote]Original post by daerid
I just wish you could put another compiler in vc++''s IDE.



You can. I use it with GCC for GBA work.


Helpful links:
How To Ask Questions The Smart Way | Google can help with your question | Search MSDN for help with standard C or Windows functions


How?

Share this post


Link to post
Share on other sites
quote:
Original post by null_pointer
I think you mean a destructor
Well, constructor too. If constructor throws stuff, the object won''t be created so the stuff it had already allocated (before throw) will never get deleted. Unless RAII is used well..

Share this post


Link to post
Share on other sites
quote:
Well, constructor too. If constructor throws stuff, the object won''t be created so the stuff it had already allocated (before throw) will never get deleted. Unless RAII is used well..


That''s probably the worst logic I''ve seen today. If we follow the same logic, then you should never through an exception from any function - the function might have allocated resources to local pointers/handles/whatever that might leak. No, wait - what if we allocate global resources and throw an exception from the class that manages said resources. Shoot, guess we can''t use exceptions at all...

Wait, we should never dereference pointers - EVER! One of them could be null due to an error in the program, and then the program might crash. Hmm...same thing with the member selection operators -> and . - I suppose we should never use pointers because due to programming errors they *might* possibly be null, causing access violation or who-knows-what-else! Oh, the horror!

By any chance, did you people hide yourselves in bomb shelters on December 31, 1999?

Share this post


Link to post
Share on other sites
Exception specifications are generally useless. You should expect every line of code to crash because the user can darn overclock his machine.

Share this post


Link to post
Share on other sites
Heh, guess I overreacted a little.

Anyway, I think that people ought to learn how to use exceptions properly instead of making excuses for not using them. "Exceptions could leak if not used properly" is not a very good reason for not using exceptions because the same thing can be said about pointers.


quote:
Exception specifications are generally useless.


...because no one likes the default. While I agree that having terminate called in a released application is a very bad idea, I also wonder what would happen if people changed the default to throw an exception of type "unexpected"? I think that might have some problems of its own, though.

If the default behavior is modified, and we do throw an "unexpected" exception object as a result of a call to std::unexpected, then we have another problem. If our "unexpected" exception object is not present in any exception specifications, then it will trigger another call to std::unexpected.

This should not crash the application because another exception object will simply be thrown. What should happen is that some execution time will be wasted repeatedly rethrowing objects until one of the unexpected exception objects is caught. This might not be much of a problem considering the circumstances.

Anyone want to share their thoughts about this angle?

Share this post


Link to post
Share on other sites