3

I have realized, after some reading, that in C++ the exceptions specification is considered a bad thing:

int f() throw(A, B);  // bad because a lot of reasons

(some references: 1, 2, etc.)

What I have not understood is how to replace it. How can I tell to the f()'s caller that he must catch an exception?

Community
  • 1
  • 1
eang
  • 1,615
  • 7
  • 21
  • 41
  • Why must the caller catch an exception. If there is an exception then something is wrong you only want to catch it if you can fix, if you can fix it you know what can go wrong. – Martin York Jan 30 '13 at 17:33

4 Answers4

7

How about

 //throws: A if something is wrong
 //        B if something else is wrong
 int f();
Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
6

You don't. Not saying anything means it can throw anything.

I assume you have some Java background to ask this question. Compile-time exception checking was a Java experiment that failed. That's why you don't see it anywhere else.

The general rule for exception handling is: handle it where you can. This usually boils down to a try-catch at some very high level, where you basically tell the user whatever he was trying to do failed. It is very rare to be able to recover from an exception and continue the operation.

You should, of course, provide documentation what exceptions your function throws. I don't consider this to be a replacement for the throw specification (its purpose is very different). You should document the exceptions that your function throws and can be handled meaningfully by the caller, whereas the throw specification has to list any exceptions that may come out of this function (and the functions it calls).

Alex
  • 7,728
  • 3
  • 35
  • 62
  • This means that try/catch must be used always? If I call a generic function I have to catch for a generic exception? – eang Jan 30 '13 at 16:56
  • 2
    @ital if you want to handle the exception, yes. But you might want to let it propagate and get handled at another level. – juanchopanza Jan 30 '13 at 16:59
  • 3
    I think a combination of Alex's answer and Luchian's answer is the best approach; document where you can but trying to force the caller to handle your exceptions is bad juju. – Jack Aidley Jan 30 '13 at 17:06
2

You could replace it with an automated documentation tool.

Such tools often have the ability to nicely format which exceptions a method will throw, like the doxygen \exception command (or \throw or \throws). Assuming users of your code read documentation, they would be able to find out what exceptions to catch.

/** 
 * @exception A 
 * @exception B
 */
int f();

See this question for more useful info: How to document all exceptions a function might throw?

albert
  • 8,285
  • 3
  • 19
  • 32
WildCrustacean
  • 5,896
  • 2
  • 31
  • 42
1

How can I tell to the f()'s caller that he must catch an exception?

That you think the caller must catch an exception indicates that there might be something wrong with your design. Are you using exceptions to signal a non-exceptional circumstance such as end of file?

Mandating the immediate callers to catch all possible exceptions is bad design. Example: The push_back member functions of the standard library containers allocate memory, which can fail. The designers of the library did not expect callers to wrap each and every push_back in a try/catch block. It doesn't make sense. Doing so would make the code much uglier, much harder to test. Besides, how would you recover from an out of memory condition? Handling this once, at a high level, is about all you can do.

David Hammen
  • 32,454
  • 9
  • 60
  • 108