Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Questions regarding ordering of catch statements in catch block - compiler specific or language standard?

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?

like image 703
Andy Avatar asked Mar 08 '10 22:03

Andy


People also ask

Does order of catch statements matter?

2. The order of catch blocks does matter. If the protected code can throw different exceptions which are not in the same inheritance tree, i.e. they don't have parent-child relationship, the catch blocks can be sorted any order.

Is the order of catch blocks important?

The order of catch statements is important. Put catch blocks targeted to specific exceptions before a general exception catch block or the compiler might issue an error. The proper catch block is determined by matching the type of the exception to the name of the exception specified in the catch block.

Why does order matter when catching exceptions?

When exception happens in the method, a special method exception table is checked, it contains records for each catch block: exception type, start instruction and end instruction. If the order of exception is incorrect, some catch block would be unreachable.

Which errors Cannot be handled by catch block?

As is documented, try/catch blocks can't handle StackOverflowException and OutOfMemoryException.


3 Answers

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

like image 161
Andrew Stein Avatar answered Oct 05 '22 23:10

Andrew Stein


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.

like image 23
Michael Burr Avatar answered Oct 06 '22 00:10

Michael Burr


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.

like image 22
AnT Avatar answered Oct 05 '22 22:10

AnT