For a library code, is it better practice to create and throw custom exception class (library::Exception), or just throw standard exceptions (runtime_error, invalid_argument, etc.)?
It's usually better to specialize (inherit) a standard exception and throw it.
This way it'll be possible to catch it as a generic exception just by catching a std::exception, but you could also catch specifically your custom exception type if you need more specialized code.
Also see this C++Faq about what to throw.
Generally you should throw instances of classes in the stdexcept header or subclasses thereof. What class exactly makes sense depends on the specific problem. I think throwing instances of “category classes” std::logic_error and std::runtime_error is rarely useful since they carry no inherent meaning; they are used to distinguish the two main situations where exceptions can occur:
Subclasses of std::logic_error should be thrown by a function if it is called, but not all preconditions are fulfilled. The exception is the fault of the caller since it has failed to provide the necessary preconditions. For this category, you generally have to choose between throwing and undefined behavior; it is a trade-off between robustness and efficiently (e.g. std::vector::at() vs. std::vector::operator[]. These exceptions often cannot be handled; they are the result of bugs in the program.
Subclasses of std::runtime_error should be thrown by a function if all preconditions are met but the function cannot meet the postconditions or breaks invariants for reasons outside the control of the program (e.g., a file doesn’t exist, the network connection is lost, or not enough memory is available). These exceptions should usually be handled.
I think the available logic error classes (e.g. invalid_argument) are often good enough, because if they are raised, the code usually has to be fixed, and there is no reason for elaborate handling routines. On the other hand, the runtime error classes in the standard library are by their nature much less flexible and cover mainly the areas where the standard library itself has to throw exceptions. For your application, you should almost always inherit from these runtime error classes. For example, a class managing the operating system resource X should throw an X_creation_error which inherits from std::runtime_error if the constructor fails to allocate the resource.
Multiple virtual inheritance is often useful with exception classes. You can inherit from std::runtime_error or other stdexcept classes, from some “marker class” specific to your library, and from boost::exception to get the additional benefits of the Boost.Exception library. The Boost.Exception tutorial is highly recommended, especially Exception types as simple semantic tags and Using virtual inheritance in exception types.
IMHO Custom exception. The customers of your library will apreciate this. He will know whats exactly raises the exception.
From experience, it is rare that you need more than a very few exception classes.
In most of my code (mainly numerics -- if you do eg. IO, the situation is different), I throw standard exeptions (runtime_error, invalid_argument, ...) because they tend to indicate something that cannot be easily recovered from (except perhaps invalid_argument), and which will likely not be caught by user code (except perhaps at the top-level to throw a message box to the user).
If there is some exception which is intended to be caught by typical user code, eg. bad_custom_cast, or bad_market_data_identifier, instead of bubbling up to main (like a failure in a numerical routine, or bad_alloc), I make a custom class. But this is quite rare actually.
Related
Is there any advantages or uses cases to throw other thing that a std::exception( or a derivatives types).
For example throw 1; or throw "error";
In other terms why the c++ standard allow it.
Per §15.1 [except]:
Exception handling provides a way of transferring control and
information from a point in the execution of a thread to an exception
handler associated with a point previously passed by the execution.
The word information illustrates everything, it can be everything such as objects, numbers, ... .
There is nothing in standard that says you must just throw std::exception. In the other words, maybe someone wants to throw his own exception objects.
Maybe someone wants to use exception-handling to handle something far from normal exceptions.
I can't think of any obvious reasons why a class derived from std::exception wouldn't typically be better.
But the throw 1 or throw "Error" are valid expressions, and they probably take a bit less "effort" creating, and there may be situations where this is a benefit. Throwing an exception type exception from the constructor of exception would probably not work very well, so there's one place.
However, it's probably more of a philosophical decision: Since throw can be made to throw a any type of object, it's not a bad idea to allow it. The more restrictions you put on things in a language, the more you restrict the possible uses of a language.
From reference material about std::exception:
std::exception
All objects thrown by components of the standard library are derived
from this class. Therefore, all standard exceptions can be caught by
catching this type by reference.
By throwing anything else, for example NuclearPlantException, you could handle your exceptions and the ones from the standard library separately. The standard library could throw std::invalid_argument or std::bad_alloc (subtypes of std::exception) and you could throw LossOfCoolant (a subtype of NuclearPlantException).
So there is at least one advantage: separating standard library exceptions from your exceptions. Because you don't throw std::bad_alloc if there's enough available space for your uranium, then any exception has a clear origin, potentially making testing and debugging easier.
Note: For more in-depth discussion see the question Should I inherit from std::exception?.
Yes, there can be advantages.
The most obvious is that the what for existing derivatives of std::exception (e.g., std::logic_error, std::invalid_argument) only deal with std::strings or char *s to specify the reason for the exception. That's probably fine if you only deal with an English speaking audience, but if you want to use the what to display an error message to somebody who doesn't use English, it can get clumsy in a hurry.
If you're using (for example) 32-bit Unicode strings throughout your program, you'd typically prefer do the same in your exception handling. In such a case, a hierarchy similar to those in the standard, but using 32-bit Unicode strings for the what argument probably makes a lot of sense. I suppose you could still use std::exception for the base of that hierarchy, but it's open to question how much (if anything) you'd gain from doing so.
Throwing things was in C++ a decade before std::exception or even std:: became an idea. This was not removed for backward compatibility reasons.
Those who chose not use std:: certainly like it that way, and throw other exceptions, likely derived from some base class supplied by a library. It's fine until you get several exception hierarchies to deal with in client code. So new code that does not fight against using std:: entirely (setting new_handler to avoid std::bad_alloc) is likely to re-fit its exception root classes to use std::exception as base.
Throwing non-class things like ints or pointers is often advised agaist, but in a light environment can make perfect sense -- in an small embedded project leaving the exceptions enabled but throwing only an enum sounds sensible.
In general, if the language allows to throw any copyable object why restrict it? While forcing to use a special library class would be not in spirit of C++ even if we had time travel.
Just as I can see in cppreference, the classic "throw" declaration lists is now deprecated in C++11. What is the reason of leaving this mechanism and how should I have to specify what exceptions throws a function of mine?
For more detailed reasoning, see: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html
As expressed in the national body comment above, exception specifications have not proven useful in practice. There are numerous discussions of the problems with exception specifications in C++ (see, e.g., [Sutter02], [Boost03]), but the main issues are:
Run-time checking: C++ exception specifications are checked at runtime rather than at compile time, so they offer no programmer guarantees that all exceptions have been handled. The run-time failure mode (calling std::unexpected()) does not lend itself to recovery.
Run-time overhead: Run-time checking requires the compiler to produce additional code that also hampers optimizations.
Unusable in generic code: Within generic code, it is not generally possible to know what types of exceptions may be thrown from operations on template arguments, so a precise exception specification cannot be written.
In practice, only two forms of exception-throwing guarantees are useful: an operation might throw an exception (any exception) or an operation will never throw any exception. The former is expressed by omitting the exception-specification entirely, while the latter can be expressed as throw() but rarely is, due to performance considerations.
[N3050] introduces a new kind of exception specification, noexcept, the specifies that the function will not throw any exceptions. Unlike throw(), noexcept does not require the compiler to introduce code to check whether an exception is thrown. Rather, if a function specified as noexcept is exited via an exception, the result is a call to std::terminate().
With the introduction of noexcept, programmers can now express the two kinds of exception guarantees that are useful in practice, without additional overhead. This paper therefore proposes to deprecate "dynamic" exception specifications, i.e., those that are written as throw(type-id-listopt).
The answer Peter gave does not hit the actual problem of exception specifications for the implementor and user:
Exception specifications cause the program to terminate (or more precisely call termination handlers) if the implementor failed to uphold the guarantee to only throw the defined exceptions.
Thus by calling a method with a exception specification you as a library user are making your own code more prone to complete failure/termination. If the library function runs out-of-memory (std::bad_alloc), you will not get a chance to catch, but you will be terminated instead.
Thus, the original goal of communicating the most likely failure options and asking you as the user to handle them was not achieved.
As an implementor on the other side, you cannot really call any other methods any more which do not have exception specifications, because these might cause you to terminate your callers. A terrible place to be in.
The conclusion is that C++ should have just gone the way that Java did it:
If you call a method with exception specification and you have an exception specification yourself, then you must catch the exception or specify it in your own exception specification.
The compiler enforces this and no other runtime effects.
Noexcept (since C++11) suffers the same conceptual mistake, since it will also cause run-time termination if the specification is not adhered too, i.e. a method throws that was declared not to. This makes noexcept impossible to use for anything serious but the most contained cases (move constructors come to mind).
They produce slower and bigger code, because libc++ has to check if any exception propagating out of a function violates it's exception specification and call std::unexpected. This is hardly ever useful, and is worse than just documenting the exceptions a function throws yourself.
Is there any advantages or uses cases to throw other thing that a std::exception( or a derivatives types).
For example throw 1; or throw "error";
In other terms why the c++ standard allow it.
Per §15.1 [except]:
Exception handling provides a way of transferring control and
information from a point in the execution of a thread to an exception
handler associated with a point previously passed by the execution.
The word information illustrates everything, it can be everything such as objects, numbers, ... .
There is nothing in standard that says you must just throw std::exception. In the other words, maybe someone wants to throw his own exception objects.
Maybe someone wants to use exception-handling to handle something far from normal exceptions.
I can't think of any obvious reasons why a class derived from std::exception wouldn't typically be better.
But the throw 1 or throw "Error" are valid expressions, and they probably take a bit less "effort" creating, and there may be situations where this is a benefit. Throwing an exception type exception from the constructor of exception would probably not work very well, so there's one place.
However, it's probably more of a philosophical decision: Since throw can be made to throw a any type of object, it's not a bad idea to allow it. The more restrictions you put on things in a language, the more you restrict the possible uses of a language.
From reference material about std::exception:
std::exception
All objects thrown by components of the standard library are derived
from this class. Therefore, all standard exceptions can be caught by
catching this type by reference.
By throwing anything else, for example NuclearPlantException, you could handle your exceptions and the ones from the standard library separately. The standard library could throw std::invalid_argument or std::bad_alloc (subtypes of std::exception) and you could throw LossOfCoolant (a subtype of NuclearPlantException).
So there is at least one advantage: separating standard library exceptions from your exceptions. Because you don't throw std::bad_alloc if there's enough available space for your uranium, then any exception has a clear origin, potentially making testing and debugging easier.
Note: For more in-depth discussion see the question Should I inherit from std::exception?.
Yes, there can be advantages.
The most obvious is that the what for existing derivatives of std::exception (e.g., std::logic_error, std::invalid_argument) only deal with std::strings or char *s to specify the reason for the exception. That's probably fine if you only deal with an English speaking audience, but if you want to use the what to display an error message to somebody who doesn't use English, it can get clumsy in a hurry.
If you're using (for example) 32-bit Unicode strings throughout your program, you'd typically prefer do the same in your exception handling. In such a case, a hierarchy similar to those in the standard, but using 32-bit Unicode strings for the what argument probably makes a lot of sense. I suppose you could still use std::exception for the base of that hierarchy, but it's open to question how much (if anything) you'd gain from doing so.
Throwing things was in C++ a decade before std::exception or even std:: became an idea. This was not removed for backward compatibility reasons.
Those who chose not use std:: certainly like it that way, and throw other exceptions, likely derived from some base class supplied by a library. It's fine until you get several exception hierarchies to deal with in client code. So new code that does not fight against using std:: entirely (setting new_handler to avoid std::bad_alloc) is likely to re-fit its exception root classes to use std::exception as base.
Throwing non-class things like ints or pointers is often advised agaist, but in a light environment can make perfect sense -- in an small embedded project leaving the exceptions enabled but throwing only an enum sounds sensible.
In general, if the language allows to throw any copyable object why restrict it? While forcing to use a special library class would be not in spirit of C++ even if we had time travel.
Although this topic has been extensively discussed on SO, I'd like to clarify a few things that are still not clear to me so, considering the following facts:
10 years ago, Herb Sutter was telling us to refrain from using this functionality.
Specifying the possible exceptions that a function / method may throw does not force the compiler to yell at you when you decide to change the function's body and throw a new type of exception, forgetting by mistake to change the exception specification in the function's declaration.
If you have a very high level function that calls several other high level functions, which each run tons of code to produce the results, then I can imagine the maintenance from hell nightmare, when I would have to specify ALL the errors which the first function may throw, and this list would have to include all the exceptions the inner functions may throw and so on, thus creating tight coupling between high and low level functions, which is quite undesirable. On the other hand, we derive all exceptions from std::runtime_error, which we know is a good practice and we could specify that the high level functions just throw std::runtime_error and be done with it. But wait a minute... Where do we actually catch the exceptions? Would it not be rather odd / nasty / bad to enclose a call to one of these high level functions in a try / catch block, which catches a MyVerySpecific exception, when the high level function is supposed to throw only std::runtime_error??? Would it be any good to catch specific exceptions in lower level functions, which are not able to do anything about them but pass them on in a more generic container, with more information appended to them? I certainly don't want to write try / catch blocks in every function that I write, just to format exceptions. It would be like requiring every function to validate its parameters, and that can drive people insane, when they need to change something in a low level function.
Questions:
Do Herb Sutter's rants about exception specification still hold today? Has anything changed since then? I am mostly interested in pre-C++0x standards. If yes, I guess we can consider this topic closed.
Since it seems that the compiler mostly ignores these exception specifications, and when catching exceptions, in 99% of the cases, one would use catch (const CustomException &ex), how would one specify that a function throws CustomException? throw(CustomExecption) or throw (CustomException &) or throw (const CustomException &)? I have seen all variations, and, although I would go for the first one, do the others make any sense / add any benefits?
How would one actually use this functionality, and, at the same time, avoid the fallacies illustrated in the above 3rd fact?
EDIT: Suppose that we're building a library. How will its users know what exceptions to expect, if we don't use exception specification? They will certainly not see what functions will be called internally by the API methods...
1/ Do Herb Sutter's rants about exception specification still hold today? Has anything changed since then? I am mostly interested in pre-C++0x standards. If yes, I guess we can consider this topic closed.
Yes, they still hold.
Exceptions specifications are:
half-way implemented (function pointers don't specify exceptions, for example)
not checked at compile-time, but leading to termination at runtime !!
In general, I would be against exceptions specifications, because it causes a leak of implementation details. Look at the state of Java exceptions...
In C++ in particular ? Exceptions specifications are like shooting yourself in the foot since the tiniest error in documentation may lead to a std::terminate call. Note that almost all functions may throw a std::bad_alloc or a std::out_of_range for example.
Note: Since C++11, throw() was deprecated and now with C++17 it is gone; instead, from C++17 on, the noexcept(false) specifier can be used. It is better supported in function pointers, but still leads to termination at run-time rather than errors at compile-time.
2/ Since it seems that the compiler mostly ignores these exception specifications, and when catching exceptions, in 99% of the cases, one would use catch (const CustomException &ex), how would one specify that a function throws CustomException? throw(CustomExecption) or throw (CustomException &) or throw (const CustomException &)? I have seen all variations, and, although I would go for the first one, do the others make any sense / add any benefits?
The compiler does not ignore the exceptions specifications, it sets up very vigilant watchdogs (which axes) to make sure to kill your program in case you had missed something.
3/ How would one actually use this functionality, and, at the same time, avoid the fallacies illustrated in the above 3rd fact?
Your customer will appreciate if it stays informal, so the best example is:
void func(); // throw CustomException
and this lets you focus on the exceptions that matter too, and let "unimportant" exceptions slip through. If a consumer wants them all ? catch(std::exception const& e) works.
4/ EDIT: Suppose that we're building a library. How will its users know what exceptions to expect, if we don't use exception specification? They will certainly not see what functions will be called internally by the API methods...
Do they have to ?
Document what matters, std::exception or ... take care of the unexpected.
Do Herb Sutter's rants about exception specification still hold today? Has anything changed since then?
I wouldn't call that a rant. He just pointed out problems related to exception specifications.
Yes, it still holds. As explained in the text, if a not specified exception is throw, the program terminates, and that is not acceptable for 99% applications.
how would one specify that a function throws CustomException?
class A
{
//...
void foo() throws( CustomException );
};
How would one actually use this functionality, and, at the same time, avoid the fallacies illustrated in the above 3rd fact?
By looking at the function declaration, the user knows which exceptions can be thrown. The problem is when a new exception needs to be thrown, then all functions declarations needs to be changed.
Suppose that we're building a library. How will its users know what exceptions to expect, if we don't use exception specification?
By reading the documentation.
This might be kind of a silly question, but in C++, when I want to throw an exception.. what do I throw?
Am I supposed to throw std::exception, or is that reserved by the standard library? Or should I throw a string or int? Or should I just throw whatever I feel is appropriate?
Throw a class that's derived from std::exception; if you #include <stdexcept>, you can pick from a number of ready-made, useful derived classes.
Deriving from std::exception allows your handlers to follow a recognizable style, as you can always use .what() to get a textual message. Don't throw primitive types, since they carry no semantic information.
Generally people don't throw std::exception directly for the simple reason that it doesn't store any error messages. There wouldn't be anything for the what method to return. I get confused sometimes over this because MSVC provides a non-standard extension to this a parameterized constructor in std::exception that accepts a string.
You can choose among existing exception classes like std::runtime_exception or define your own. This is somewhat subjective but I recommend keeping the number of exception classes to a minimum as RAII can eliminate a lot of the need to have multiple code branches and catch blocks for different exception types. Often the message combined with RAII-conforming code is enough to gracefully recover from any exception.
And finally, I recommend all exceptions you throw inherit from std::exception for similar reasons. You don't want to have to litter your code with many different catch blocks for different exception types if you can avoid it. Solve the problem as generally as you can.
The primary exception to throwing something derived from std::exception would be if you're using some framework (e.g., MFC) with its own exception hierarchy. In that case, you generally want to derive from an appropriate spot in their hierarchy instead.
Note that I'm not particularly attempting to hold MFC up as an example of clean exception handling (or clean design in general), only an example of a framework that includes an exception hierarchy. When you're using a framework that already defines an exception hierarchy, you're generally better off using it.
In other words, unlike the preference in C++ otherwise, it's generally accepted that exceptions should be a single, monolithic hierarchy with a single root. For the standard library, that single root is std::exception, but other frameworks have alternatives, and if they provide one you generally want to fit yours into it.
Unlike java you CAN throw whatever (int, string, MyClass, ...) you want. But listen to Kerrek. :)
Usually you'll want to throw one of the exceptions derived from std::exception as others have said.
On occasion I've thrown other types, but only if it's caught within the same block and the value is something useful in that context.