try-throw-catch

Originally Posted by anon

Code:

void FileHandling::ReadFile(const string& filename) throw(int)

Again you are saying you would throw int's. Either don't use a throw specification at all or be honest about it. The compiler won't forgive.

Concerning error specifications, you are using new which might throw std::bad_alloc, so the specs are wrong.

Instead of allocating memory with new you should use a std::vector, or otherwise you'll leak the allocated memory when the function throws (or handle that clean-up manually - your choice).

You're right , but not thoroughly. I use new only after those two first throws, and the error happens on the first throw, before using new...

Originally Posted by Daved

The throw specification is the part at the end of the function declaration:

Code:

void ReadFile(const string& filename) throw(int);

I just meant to remove those, since those aren't mandatory and you can still use try/catch/throw without them (and many would suggest that you not use them).

I already tried changing it. (#27) and it didn't work...

Did you try removing it? Like this:

Code:

void ReadFile(const string& filename);

Originally Posted by Daved

Did you try removing it? Like this:

Code:

void ReadFile(const string& filename);

Yep. Still, the same problem. While performing throw it says

Unhandled exception at 0x00435768 in HW0.exe: 0xC0000005: Access violation reading location 0xccccccc0.

and shows me dbgdel.cpp, with a line contains "_ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));"

I tried running the code and found the problem. The issue was the same as the crash I mentioned earlier when you create a FileHandling object but don't call ReadFile. When you exit from ReadFile early (before the dynamic array is created) you get the same problem, it causes a crash when the FileHandling object is destroyed.

The reason is that you don't initialize vec, so when the destructor tries to delete it then it tries to call delete on a garbage memory location. The best solution of course is to use the vector class. But if you aren't allowed to, then just initialize vec to 0 in the constructor and the delete will not cause any problems if it is never set to another value.

Also, if you must keep the dynamic array, you should disable copying so that you don't get crashes when your class is copied.

Originally Posted by Daved

I tried running the code and found the problem. The issue was the same as the crash I mentioned earlier when you create a FileHandling object but don't call ReadFile. When you exit from ReadFile early (before the dynamic array is created) you get the same problem, it causes a crash when the FileHandling object is destroyed.

The reason is that you don't initialize vec, so when the destructor tries to delete it then it tries to call delete on a garbage memory location. The best solution of course is to use the vector class. But if you aren't allowed to, then just initialize vec to 0 in the constructor and the delete will not cause any problems if it is never set to another value.

Also, if you must keep the dynamic array, you should disable copying so that you don't get crashes when your class is copied.

You little... :-)))
Oh man...you're the best. It's 1:20Am here, I hardly see, almost lost hope and you did it. You've got no idea how much I thank you.

Another thing: you use delete, but new[]. You must match the array and non-array forms of new and delete correctly. If you allocate with new[], you must deallocate with delete[].

Originally Posted by CornedBee

Another thing: you use delete, but new[]. You must match the array and non-array forms of new and delete correctly. If you allocate with new[], you must deallocate with delete[].

Correct! Thanks!

Another note about throw(type):
Visual Studio doesn't support throw(type), so rather you should use throw(...) if anything at all. Unless you don't want your code to compile with Visual Studio.

The code will compile fine, it will just generate warnings. If you want exception specifications for whatever reason, then you'll have no problems porting your code to Visual Studio.

throw(int) doesn't work.
throw(...) does, though.
Visual Studio doesn't support throw(type) specifications, for whatever reason...

It compiles and runs for me (VC++ 7.1). Not sure why you think it doesn't work.

OK, so that's weird because I'm sure it didn't work in 2005.
In 2008 I just get a warning that the compiler ignores it because it's not implemented.