Classes and error handling

This is a discussion on Classes and error handling within the C++ Programming forums, part of the General Programming Boards category; >> Like this?
Yes. You might also consider taking the string as a const reference, although that shouldn't be a ...

>> Like this?
Yes. You might also consider taking the string as a const reference, although that shouldn't be a big deal.

>> they all have been constructor calls for that type. Right?
Pretty much, yes. Obviously plain old datatypes don't actually have constructors, but the idea is the same.

>> So if I throw before allocating, there would still be a memory leak?
If you throw before allocating, then there would not be a leak. If you throw after allocating, there would be a leak (unless you deallocate before throwing). However, in most cases (at least in your pseudocode) you don't need to do any allocating on your own, so you don't have to worry about it. The ifstream and string classes will clean themselves up.

>I'm not sure if I follow you on this one, Prelude...
Exceptions are a bulky and time consuming process in C++. As such, they should be reserved for truly abnormal behavior to avoid the overhead and code bloat. Let's assume that giving the user control over something produces a random correct/incorrect result over a controlled sequence. That said, we can expect about 50% of the files that the user wants to open to have some kind of problem that would cause the open to fail (misspelled name, wrong directory, non-existent file, etc...). A failure condition for half of the requests is not abnormal behavior, so throwing an exception isn't the best option for a user controlled file open.

Speed of execution is rarely a consideration in most cases where you need to open files. It's rare to do anything like opening files in a time-critical section of code (if for no other reason than opening files is itself time-consuming). After a failed open, your program is almost certainly going to be idle and waiting for user input to confirm whether it should abort/retry/whatever, and whether that dialog pops up in 0.05 seconds or 0.07 seconds isn't really a big deal. The user won't visually see a difference.

In general I think the benefits of throwing an exception outweigh the negligible performance hit.

As for the try block, I hope you don't mean "terminate program here" by means of the terminate function or anything similar. If you want you can log the error and do any cleaning you may feel like... but the proper way to terminate is to rethrow the error afterwards.

... and if user is smart enough, they might even figure out what to do about FatalError?

As for the speed question, yes, in this particular constructor speed would not matter. However, speed might be a concern if I did exception handling with read/write operations, which might be in loops. I'll just need to test and see if that would be that bad.
[edit]
But then. If the first error is encountered, the error handler should exit the loop after all?! Would there be enormous overhead then?

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

The results on this test are variable -- multiple runs through the code show almost equal time; sometimes one is faster, sometimes the other.

Overall, the time difference between a single throw() and a single error return is on the order of 500 nanoseconds (0.0000005 seconds) which in most cases is not going to be your speed-limiting factor.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell