{ case 1 : cerr << "Error opening file...

Ludzie pragną czasami się rozstawać, żeby móc tęsknić, czekać i cieszyć się z powrotem.

" << endl; break;
case 2 : cerr << "Insufficient amount of data." << endl; break;
// ... etc.. etc..
Now this has created a much more robust program, but it is kind of a syntactical nightmare...
First of all your LoadData() function has sixteen different return statements (and one of the rules of programming I was taught was that each function should have one point of entry, and one point of exit, I know that I personally break this rule a lot, but I really do try not to.) To solve this problem, all we have to do is turn to the beauty of exceptions. When can create code that has almost exactly the same effect as above, but is a little more robust very easily. Our main now looks like...
int main(void)
{
// Code goes here ...
try
{
LoadData(Filename);
}
catch (int loadResult)
{
switch (loadResult)
{
case 1 : cerr << "Error opening file." << endl;
break;
case 2 : cerr << "Insufficient amount of data." << endl; break;
// ... etc.. etc..
}
}
// Continue program ...
}
and our LoadData routine would look like
void LoadData(char* filename)
{
// code here ....
if (!fopen(filePointer,filename))
{
throw 1;
}
// more code ....
if (feof(filePointer) && dataNotFinished)
{
fclose(filePointer);
throw 2;
}
// more code ....
if (current_data < 0 or current_data > 5000)
{
fclose(filePointer); // Invalid data
throw 3;
}
// more code ...
return;
}
Now, this is a small improvement, but I doubt I could convince anyone to buy into exceptions if this is all they did. However, I using this just as a simple example. The module throws an exception, and the client catches it. The process is as follows, once an exception is thrown the program looks for anything that is willing to catch it. If nothing catches it you get an ugly message from the runtime engine. If it reaches a catch statement it determines whether or not the catch statement was designed to catch that type of exception. In the above example we are throwing an integer exception, and the catch statement is designed to catch integers so the program will hand control over to the catch statement and continue execution. The whole process is very clever, and it will unwind as many layers of call statements as it needs to reach an appropriate handler.
Like I said, if all exceptions could throw was integers, then we wouldn't find them very appealing.
Of course you could throw and enumerated error type that would make much more sense to the reader of the code, but still that produces a lot of limitations. Let's try throwing a null termated string instead...
int main(void)
{
// Code goes here ...
try {
LoadData(Filename);
}
catch (char* errorMessage)
{
cerr << errorMessage << endl;
throw; // Note: we could place an exit(1) here, or something, but this
// will do the same thing by propagiting the exception, the
// C++ run-time engine will produce a nice error for the
// user that may or may not be meaningful (but they will
// also have the message we sent them...
}
// Continue program ...
}
void LoadData(char* filename)
{
// code here ....
if (!fopen(filePointer,filename))
{
throw "Couldn't open file!";
}
// more code ....
if (feof(filePointer) && dataNotFinished)
{
fclose(filePointer);
throw "Not enough data to fill object!";
}
// more code ....
if (current_data < 0 or current_data > 5000)
{
fclose(filePointer);
throw "Invalid data!";
}
// more code ....
return;
}
Now are we beginning to see why this is such a nice and powerful tool? It also helps to create self documenting code, which is an added bonus. But it doesn't end there, through the magic of object oriented programming we can create exception objects and throw them as well. These Exception Objects can be much more complicated objects that can carry a lot more data. In fact, they can be polymorphic objects that can carry code that can be executed when the exception occurs (if you catch a base class, that class will catch any objects inherited from the base class. You have to be careful with this since, if you want to catch the inherited class you have the place that catch statement before the catch statement for the base class). Now all of this polymorphism and OOP can get a little complicated, so lets back up the programmers express and just create a simple exception object.
class ExceptionObject
{
// Note: The string class I am using here is <cstring.h> (a close
// realative to AnsiString), but any string class which has a char*
// constructor, and overloads the '<<' operator for output will work.
public:
// Simple constructor. Uses syntactic sugar (initialization,
// whatever) to initilize data members.
ExceptionObject(const string &Module,int LineNo,const string &Error)
: _Module(Module),_LineNo(LineNo),_Error(Error) {}
// Always make your destructors virtual if you are going to
// inherit from the object...
virtual ~ExceptionObject () {}
// Simple accessors...
const string& Module() const { return _Module;}
int LineNo () const { return _LineNo;}
const string& Error() const { return _Error;}
// Right now this is a pure virtual function (it doesn't do anything
// but later versions might...)
const virtual void HandleException() {}
private:
string _Module, _Error;
int _LineNo;
};