I always catch exceptions by value. e.g
try{
...
}
catch(CustomException e){
...
}
But I came across some code that instead had catch(CustomException &e) instead. Is this a)fine b)wrong c)a grey area?
views:
361answers:
4
+2
A:
Catching by value will slice the exception object if the exception is of a derived type to the type which you catch.
This may or may not matter for the logic in your catch block, but there is little reason not to catch by const reference.
Note that if you throw; without a parameter in a catch block, the original exception is rethrown whether or not you caught a sliced copy or a reference to the exception object.
Charles Bailey
2010-03-26 09:58:42
+9
A:
The standard practice for exceptions in C++ is ...
Throw by value, catch by reference
Catching by value is problematic in the face of inheritance hierarchies. Suppose for your example that there is another type MyException which inherits from CustomException and overrides items like an error code. If a MyException type was thrown your catch block would cause it to be converted to a CustomException instance which would cause the error code to change.
References
JaredPar
2010-03-26 09:59:04
To this I would add: catch by const reference. Unfortunately you can throw a const object and catch it with a non-const reference. To avoid this silent "casting away" of const, always catch a const reference, and ensure your exception types have const-correct accessors.
Daniel Earwicker
2010-03-26 10:01:13
@Danial Earwicker: Why is it "unfortunate" that you can catch via an non-const reference?The exception object is always copied so whatever 'object' you throw, you can't affect the original from any catch block as the 'object' thrown was really just an initializer. There's no casting away of const; exception objects are always non-const, non-volatile. Allowing a catch via non-const reference enables intermediate catch blocks to add information to the exception. It's not commonly used but it's there if you need it.
Charles Bailey
2010-03-26 10:06:38
Can you provide a reference please, if you want the accepted answer :)
John
2010-03-26 10:07:12
@John: Chapter 15 Exceptions, specifically 15.3 (exception handling) describes how the catch parameter is initialized from the exception object. Where the parameter is a class type (rather than a reference) it is initialized via a copy-constructor.
Charles Bailey
2010-03-26 10:12:34
@Daniel: to clarify Charles (and deliver to your inbox), the exception object you can catch and rethrow is by definition a temporary. The argument to `throw` should be on the stack and should be destroyed as the first order of business of unwinding. `throw new` is an error.
Potatoswatter
2010-03-26 10:55:02
@Charles - You're right, it's not really casting away of const. I guess I think of it in the same terms as a temporary being passed to a method by non-const reference, which is banned elsewhere in the language to avoid attempts to mutate a temporary via the reference (when the mutation is going to be discarded anyway). But as you say, you might want to deliberately mutate the exception and then `throw;` which makes it visible elsewhere (thus breaking my analogy).
Daniel Earwicker
2010-03-26 10:59:53
A:
Unless you want to fiddle with the exception, you should usually use a const reference: catch (const CustomException& e) { ... }. The compiler deals with the thrown object's lifetime.
Marcelo Cantos
2010-03-26 09:59:53
A:
in (CustomException e) new object of CustomException is created... so it's constructor will be called while in (CustomException &e) it will just the reference... not new object is created and no constructor will be called... so formal is little bit overhead... later is better to use...
mihirpmehta
2010-03-26 10:05:53