Declaring function that throw exceptions
-
I believe that, in C++, if a function may throw an exception, you should declare it like this:
int myfunc() throw (CMyException);The problem is that VC (even .NET) issues a warning that it disregards my declaration as the ANSI standard is not very specific when using functions that throw exceptions. In fact, I think the function may very well throw an exception of another type, not the one declared. The question is: Do you decorate your function declarations with an exception specification or don't bother since it does not matter. Why? Because it is good design? Also, if you do, do you use thethrow (CMyException)both in the header and the implementation file? Best regards, Alexandru Savescu -
I believe that, in C++, if a function may throw an exception, you should declare it like this:
int myfunc() throw (CMyException);The problem is that VC (even .NET) issues a warning that it disregards my declaration as the ANSI standard is not very specific when using functions that throw exceptions. In fact, I think the function may very well throw an exception of another type, not the one declared. The question is: Do you decorate your function declarations with an exception specification or don't bother since it does not matter. Why? Because it is good design? Also, if you do, do you use thethrow (CMyException)both in the header and the implementation file? Best regards, Alexandru SavescuThe function my thow any other exception, but if it do so your aplication will be terminated because the 'unexpected' handler will be called witch by default call 'terminate'. To set your own handler you can call 'set_unexpected()'. For a more deep perspectiv on exception you can see "Deep C++" in MSDN Bye, Orbital^ ...the night is long ... but not long enought to do some real coding ...
-
The function my thow any other exception, but if it do so your aplication will be terminated because the 'unexpected' handler will be called witch by default call 'terminate'. To set your own handler you can call 'set_unexpected()'. For a more deep perspectiv on exception you can see "Deep C++" in MSDN Bye, Orbital^ ...the night is long ... but not long enought to do some real coding ...
Are you saying that if I do:
void f () throw (MyException)
{
throw OtherException();
}//and then
void g()
{
try
{
f();
}
catch (MyException)
{
}
catch (OtherExcepion)
{
}
}my application will be terminated. I doubt it! Best regards, Alexandru Savescu
-
Are you saying that if I do:
void f () throw (MyException)
{
throw OtherException();
}//and then
void g()
{
try
{
f();
}
catch (MyException)
{
}
catch (OtherExcepion)
{
}
}my application will be terminated. I doubt it! Best regards, Alexandru Savescu
In ANSI C++ the program will be terminated but as Visual C++ documentation say : "A function is declared using exception specification, which Visual C++ accepts but does not implement". If you want to write compatible code you should respect ANSI specification. MS say : "Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications." Bye, Orbital^ ...the night is long ... but not long enought to do some real coding ...
-
I believe that, in C++, if a function may throw an exception, you should declare it like this:
int myfunc() throw (CMyException);The problem is that VC (even .NET) issues a warning that it disregards my declaration as the ANSI standard is not very specific when using functions that throw exceptions. In fact, I think the function may very well throw an exception of another type, not the one declared. The question is: Do you decorate your function declarations with an exception specification or don't bother since it does not matter. Why? Because it is good design? Also, if you do, do you use thethrow (CMyException)both in the header and the implementation file? Best regards, Alexandru Savescu****Alexpro wrote: The question is: Do you decorate your function declarations with an exception specification or don't bother since it does not matter. Why? Because it is good design? Also, if you do, do you use the throw (CMyException) both in the header and the implementation file? Exception specifications in C++ are broken. If you specify a function as having an exception specification (and if the compiler conforms to the standard) then any exception that the function throws that isn't in the specification causes the unexpected exception handler to be called which defaults to terminating the program. This is considerably different to how they work in Java. Java has static checking of exception specifications which means that you can't write a function that calls another function yet doesn't either handle the exceptions specificed in the other functions exception specification or declare that exception in its own exception specification. It's a complex problem to make a C++ compiler do this static checking as it would most probably need sight of all source used for a start as there's probably not enough information in the resulting object files. There's then the issue of whether it's a good idea to have it do that checking... In Java it's often a pain to have to modify lots of code when a library changes its exception spec. It wouldnt be so bad if the callers actually did stuff with the new exception, but often they don't, they just pass it on up the chain. Of course if each library caught every exception and translated the appropriate ones into their own more descriptive exceptions then that wouldnt be so bad, but you can find yourself upgrading a library and suddenly having to deal with 'blah.blah.sublibrary.we.now.use.exception' which, as I said, is a pain. If everyone did the right thing it would possibly be a good thing and add value, but people, being people, dont, and it isn't. So, my view is that in Java it's a pain and isn't used properly and in C++ it's a liability and should be avoided at all costs unless you want your programs to just terminate randomly. To write robust code in C++ using exception specs you would need to wrap all access to any code that you didnt have sight of the source of in a try/catch block which translated all exceptions into something you knew. If one developer fails to do that in one library anywhere in your source tree then your program may just decide to exit. To be really sure you'd have to wrap ALL