Delete[] Error...

This is a discussion on Delete[] Error... within the C++ Programming forums, part of the General Programming Boards category; I just threw together a quick exception handling class, and when I use it, I'm getting an error for some ...

Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah

You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie

Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah

You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie

Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah

You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie

Naturally I didn't feel inspired enough to read all the links for you, since I already slaved away for long hours under a blistering sun pressing the search button after typing four whole words! - Quzah

You. Fetch me my copy of the Wall Street Journal. You two, fight to the death - Stewie

You might as well add a copy assignment operator to that while you're at it. Otherwise it will cause the same problem as the lack of a copy constructor did. The assignment operator would have to delete the currently stored error string, or use the swap trick to let the destructor do it automatically.

You should catch exceptions by reference, there's no reason not to and in this case might save some unnecessary copying.

Using the C++ string class would mean that the copy constructor, copy assignment operator and destructor wouldn't even be necessary for your class. It would just work.

Use std::string and the sizeof is not required for new, new already knows what size each object is, it just needs to know how many to make.

That's only true under the assumption that it will remain a char. I, myself, was assuming that in his actual class he might be opting to use TCHARs for full compatibility. And, of course, if he is, he'd have to use _tcscpy() and _tcslen() instead of strcpy() and strlen(), respectively.

As a general rule, it is not a good idea for any type that you throw as an exception to use dynamic memory allocation. The reason is that the process of creating the exception, or copying it around (which is potentially required during stack unwinding) can throw an exception. That can result in calling code receiving an exception it doesn't expect (eg if the memory allocation fails) or [depending on how it happens] either undefined behaviour or a call to abort() if a second exception gets thrown while the first is active.

That also means that using std::string within an exception type is a bad idea; std::string uses dynamic memory.

is also a problem as it implicitly passes a copy of a local string around in the exception. The result may not show up in the specific example (the exception is both thrown and caught in main()), but yields undefined behaviour. To make it obvious, consider that happens if the exception is thrown from a function called by main(): e.GetError() will point to a string that was in scope at the throw point, but not when it is caught.

If "Error!" is a constant string literal, then it won't go out of scope, so JaWiB's example is fine, correct?

No.

Strictly speaking (the letter of the standard) it is out of scope for the caller and therefore an access to it (particularly dereferencing it) yields undefined behaviour. In practice, what you say is often true, but that's because compilers and linkers do not tend to truncate lifetimes of constants if there is enough free resources around to allow them to keep existing without thrashing the system. But on systems which are short of memory, the compiler and linker can (and will) purge from memory or caches anything that is no longer required to exist --- and local constant strings are a prime candidate for that.