Exception types should use virtual inheritance when deriving from other exception types. This insight is due to Andrew Koenig. Using virtual inheritance prevents ambiguity problems in the exception handler
Throwing and catching an exception in the same place is not good idea at all. Using exception for non-exceptional situations too.
You should not use exceptions as flow control.
Your example is not doing what you want: even if you enter invalid speed, Car instance will be created and rest of the progra would not know about invalid state.
You should not create new exception types except in some rare cases, exception description is where you want to place error description.
You should catch exceptions by reference, not value to prevent slicing and preserve real exception type.
Your example is not doing what you want: even if you enter invalid speed, Car instance will be created and rest of the progra would not know about invalid state.
So I sould use the try/catch construct in the main, for example?
//outside the main
1 2 3 4 5 6 7
//outside the main
//constructor: initialize the speed
Car( int speed, constint limit ) : os( speed ), limit( limit )
{
if (speed > limit || speed < 0) throw os;
elsethis->speed = speed;
}
1 2 3 4 5 6 7 8
#include "OverSpeed.h"
//in the main:
try {//in this case if the exception is thrown the car is not created, right?
Car car1(200, 100);
} catch ( OverSpeed &ex ) {
cout << "ERROR: " << ex.what( ) << endl;
}
I'm not 100% on this, but I really wouldn't suggest throwing your class object. It may be better to try and gather a certain input, if that input is not valid, throw a certain enumerated exception.
With exceptions you want to try and avoid giving the user an opportunity to input invalid data. The idea of an exception is to catch invalid data to prevent a bad program state.
You could even try to make a separate method to read your speed and other member variables to prevent data being corrupted.
By doing something like this with an array, you prevent the user from accessing an invalid index of the array. You can try to implement something of the same logic in your program with your member variables
http://ideone.com/iu8BHh
Example of slicing. Note that two catch blocks outputs different lines because of catching by value in first case.
wouldn't suggest throwing your class object.
And I would suggest to throw classes. You will get benefits of inheritance, can hold nessesary info for exception handler and can wrap all manipulations in itself.
So I sould use the try/catch construct in the main, for example?
The problem here is one that you are already aware of, this example is a little too trivial. You're trying to use exception handling where input validation belongs. In the real world with something like this you wouldn't exit your constructor, you would instead prompt the user to reenter valid input.
A better example would be something like running out of memory or disconnecting from a data source. Say you had a program that should grab 'X' number of data samples, perform some operation on the set, and then write the result to the disk. But for some reason the system runs out of memory before you reach 'X' or your system loses it's network connection or the program was told to shutdown unexpectedly. In this case you could throw an exception to interrupt the programs execution, process what you have and then write the result to the disk while probably popping a message up for the user then go do what you think is necessary (die, attempt to reconnect etc.). Keep in mind that exceptions aren't mandatory for every program, they are a design consideration.