views:

120

answers:

3

I am currently using Visual Studio Express C++ 2008, and have some questions about catch block ordering. Unfortunately, I could not find the answer on the internet so I am posing these questions to the experts.

I notice that unless catch (...) is placed at the end of a catch block, the compilation will fail with error C2311. For example, the following would compile:

catch (MyException)
{
}
catch (...)
{
}

while the following would not:

catch (...)
{
}
catch (MyException)
{
}

a. Could I ask if this is defined in the C++ language standard, or if this is just the Microsoft compiler being strict?

b. Do C# and Java have the same rules as well?

c. As an aside, I have also tried making a base class and a derived class, and putting the catch statement for the base class before the catch statement for the derived class. This compiled without problems. Are there no language standards guarding against such practice please?

+3  A: 

From C++ Standard 15.3/5 "Handling an exception":

The handlers for a try block are tried in order of appearance. That makes it possible to write handlers that can never be executed, for example by placing a handler for a derived class after a handler for a corresponding base class.

A ... in a handler’s exception-declaration functions similarly to ... in a function parameter declaration; it specifies a match for any exception. If present, a ... handler shall be the last handler for its try block.

Michael Burr
Any idea why the Standard doesn't forbid it? Looks like a stupid pitfall that's easy to avoid by making it illformed.
Johannes Schaub - litb
Michael, thank you for your answer. Johannes, thank you for the question - this is what I am wondering as well.
Andy
@litb: no idea at all. I'd be interested in a comment from anyone who might know (or has a good guess).
Michael Burr
+5  A: 

According to the standard, the order is significant. Basically the first catch that matches the exception will be caught.

a) Because catch(...) will make any following catches irrelevant, the standard only allows it to be the last catch.

b) C# and Java have similar rules.

c) catch (by reference or pointer) of a base before a derived class will make the code for the derived irrelevant. However, the standard does allow this

Andrew Stein
a) is true (the first two sentences). catch(...) is special-cased because no later clause could ever match, so later clauses are completely forbidden.
Ben Voigt
Reworded according to these two comments. Thanks Johannes and Ben
Andrew Stein
+3  A: 

The so called default handler catch(...) must be the last handler in the list of handlers. This is indeed required by the standard. However, this requirement is specific to default handler.

Otherwise the standard does not restrict the ordering of the handlers, meaning that generally you can create a handler that would "intercept" all exceptions that would otherwise reach some other handler down the list (thus making the latter handler useless).

Moreover, it is perfectly legal to repeat the same catch clause (with the same type) several times

catch (int) {
  // ...
}
catch (int) {
  // ...
}

even though only the first one will have a chance of ever catching anything. A good compiler will issue a warning for cases like that, but formally it is not an error.

AndreyT
Thank you. I did not know that you can have two catch statements catching exactly the same data type!
Andy