Printable View
I am trying to debug my program but it keeps on crashing on the "new" operator. But if I run the program without debugging into the code it works fine. If I set my breakpoints at different places the program crashes at different "new" operators.
I don't know what to do. HELP!
The first thing I do when I see such strange behavior is rebuild everything. Clear out all the .obj, .exe, .dll files--all the files you create in your build--and try again after a clean build.
If that doesn't help, there could be some memory corruption going on. I'd check what changed recently.
Also, you could be mixing debug and non-debug items in the same build, which should be avoided.
Jeff
In C++ with exceptions, You can't get away with writting a "new" without wrapping it with a try/catch block. Remember, EVERY TIME you write down a "new", always put a try/catch to wrape it.
That's because the evil C++ exceptions. constructors ARE allowed to fail. And when that happens, an exception is thrown. So you have to use try/catch to catch that.
Although it's a good idea to handle exceptions, you don't have to put them around every new. You most likely won't be in a place where you can easily handle an exception. I'd suggest putting it up a few levels at a subsystem level. Then catch particular individual 'new's that are suspect.
However, catching exceptions won't fix the OPs problem. I still suspect a build issue.
Jeff
AnthonyMai said:
>>>>>>
That's because the evil C++ exceptions. constructors ARE allowed to fail. And when that happens, an exception is thrown. So you have to use try/catch to catch that
<<<<<<
... not to mention the fact that that uncaught exceptions are
thought of as logic errors. In my opinion, it's a good idea to wrap all of your code in main() with at least a try/catch-all so that you catch exceptions, but obviously more detail would be better. I don't know why I'm bothering to say this, but I wouldn't characterize C++ exceptions as evil; take Mai's opinions [as well as my own] with a grain of salt.
--Paul
C++ Exceptions are evils because in real life, every one wants to throw an exception upon any minor error condition. But no one bothers to write any try/catch code.
Check many of the sample code Paul M., Philips, Paul W. et al posted. None of them ever bothered to put in a try/catch.
In principle, any of the STL functions they can, even something as innocent as cout << "Hello!", could potentially fail UNEXPECTEDLY, and hence such calls need to be wrapped in try/catch. In practice, no one bother to do that.
C++ are evils also because of the ambiguity on who should catch the exception and what kind of exception could be thrown. By simply writting:
There are any where from a few to a few hundred possible types of exception object potentially getting thrown out, depending on the complexity of the class. The catcher has no idea what they are and can't use them to help find where the problem is, unless the caller of new SomeClass() is totally familiar with every inner functions that could potentially be called within the "new" operation.Code:SomeClass* pObj = new SomeClass();
I feel myself getting sucked in, but oh well.
>>>>>
But no one bothers to write any try/catch code.
<<<<<
When writing code to post on a website, usually SAMPLE code is
given. It's assumed that the user will do error-checking on his
own. This is why you will see a paucity of try/catch blocks in code
posted on the forums.
>>>>>
SomeClass* pObj = new SomeClass();
There are any where from a few to a few hundred possible types of exception object potentially getting thrown out, depending on the complexity of the class
<<<<<
There are exception specifications; these are intended to let the
client of a class know which exceptions a function can throw. If a
class is poorly designed where it can throw hundreds of
exceptions, then I probably wouldn't use it. Of course, there are
only a small number of exceptions in the C++ standard library. If
you're getting hundreds of possible exceptions that come with a
3rd-party library, why not use their documentation? In addition,
there's a strong possibility that they will use an intelligent hierarchy so that you can catch the base-class of their exception
class:
At the very worst, putting that in your main() would catch whatever hundreds of exceptions you'd encounter. Of course, itCode:try
{
executeThirdPartyFunction();
}
catch (ThirdPartyExceptionBaseClass& ex)
{
cerr << "A exception from ThirdPartyApplication of type " << typeid(ex).name() << "was thrown with context: " << endl;
cerr << ex.what() << endl;
}
catch (exception& ex)
{
cerr << "An exception of type " << typeid(ex).name() << " was thrown with context:" << endl;
cerr << ex.what() << endl;
}
catch (...)
{
cerr << "An unknown exception was thrown." << endl;
}
makes a lot of sense to catch exceptions a lot closer to where
they're being thrown, but again -- I wouldn't characterize exceptions as evil.
--Paul
When writting a try/catch block, you have to handle not only the exceptions directly thrown from the function you call, but also the exceptions thrown by one of the inner function calls and never caught in the inner call stack, because you never know what sort of exceptions are caugh or let go underneath. This is demanding you need to have far more knowledge of the implementation details underneath than you should. This is very bad and breaks one programming principle that exposing only the interface but hide implementation details.
See the trouble with the sample code you just posted? To baby-sitting just one function call, you need 10 other code lines to take care of the exceptions. If the underlining functions could potentially thrown 100 different exceptions, and you have to presume the worst (since you have no idea about the underneath code) that none of the inner function calls bother to catch exceptions, you literally have to write 100 lines of code to baby sitting one function call properly.
The traditional error code return would be more superior. Ever layer need only worry about the return values of the direct function calls, but not the result of any inner function calls. Where the underlining function could not possibly fail, it can just return void.
When dealing with any third-party library, you only have two
groups of exceptions to deal with: the exceptions in the standard
library and the exceptions in that library. If the implementors of
this library do not use an intelligent exception hierarchy, I'd be
wary with trusting their product. Assuming they do use an
intelligently designed hierarchy, you're adding a few lines to cover
THEIR exceptions ... a few to cover the ones from the standard
library ... and a few to cover ANY exception.
To respond to the claim that you will be using 10-20 lines of code
to babysit one function, in the worst case scenario, you would
be correct. It's much more likely, however, to see more than
one statement surrounded by try/catch's. Because you don't have
to catch the exception immediately following the function that
threw it, you can separate what your'e trying to do from the
error handling.
Here's a rudimentary example:
Code:try
{
function1();
function1();
function2();
function3();
function4();
function5();
function6();
function7();
function8();
function9();
}
catch (ThirdPartyException& ex)
{
// ...
}
catch (exception& ex)
{
// ...
}
catch (...)
{
// ...
}
It's just a matter of personal preference; you might like to check
return codes after each individual function call while others like to
separate the error reporting/handling from the code a little bit
more. I didn't want your assertion that "exceptions are evil" to
be the only voice heard so I inputted my two cents as well.
--Paul
Try reading "Exceptional C++" by Herb Sutter. This covers exception safety in great detail with barely a try/catch in view. Wrapping every new in a try/catch would be stupidity of the first order. It is not necessary to catch an exception to be exception-safe. Often, the strong exception safety guarantee (if an operation fails because of an exception, program state remains unchanged) can be provided with minimal design effort. By implementing the strogn guarantee, you make life much easier for those few, strategically placed, catch blocks that try to take sensible action after failure.
If I ever came across a "programmer" who threw an exception for anything other than an exceptional condition, they would be sent packing with a flea in their ear. Throwing an exception on any minor error is a serious programming fault, akin to overusing public inheritance, for example.
I absolutely agree. Unfortunately the culture of the general programming public believes otherwise. C++ exception was originally designed for some good intention but it is being used abused. That is why I call C++ exceptions are evils.Quote:
If I ever came across a "programmer" who threw an exception for anything other than an exceptional condition, they would be sent packing with a flea in their ear. Throwing an exception on any minor error is a serious programming fault, akin to overusing public inheritance, for example.
You have to catch an exception some where to be exception-safe. Unfortunately there is no rule to follow who should catch an exception and who should just let it pop to upper level. Because no one want to be "stupidity of the first order", the end result is exceptions never get caught. Un-caught exceptions can be accounted for a considerable portion of all software bugs we see today.Quote:
Wrapping every new in a try/catch would be stupidity of the first order. It is not necessary to catch an exception to be exception-safe.
That's the culture I see, every one want to take the convenience of throwing an exception, but no one bothers to write a try/catch. And whoever writes a try/catch is considered "stupidity of first order". That is bad.
By its original intention, exceptions are designed for such error condition that is never expected in the first place, that local recovery is impossible, and that continuing will have catastrophic result. But since its invention, exceptions is so wide-spread today that it is used daily to return perfectly normal and expected error conditions, or even further, even if the condition is not an error, but merely some thing undesirable, one would thrown an exception, too. If a user inserts CD #2 instead of #1 as requested, an exception is thrown.
Ironically, one has to manually write code lines to throw an exception. The moment you write the "throw" down, you clearly indicate that you know some thing COULD go wrong and you EXPECTED that to happen. So it is no longer an exceptional condition. So by all means you should just return an error condition to the caller, instead of throwing an exception.
Exception is NOT without a price. When there are exception code, you are forcing normal tasks to carry the extra burden to book-keep the information needed by the exception handler. You pay a performance price for something rarely occurs.
Function interface protocols are contracts between function caller and callee. The caller promises to provide expected parameters and check any error code that returns (or take the consequence if returned error code is not checked.) The callee promises to carry out the task and return an error code if something goes wrong.
There is no such contract for exceptions. By looking at the header file, you never know if a function throws any exception, further you don't know if that function catch any exception thrown from sub-functions. Also you don't have any obligation to catch any exception. If you do, you are stupid of the first order. If you don't, it's not your fault, you can blamn upper level code for not catch the exception. See the irony? Once exceptions are introduces, chaos is introduced into the code.
Will you please stop putting words in my mouth!Quote:
you don't have any obligation to catch any exception. If you do, you are stupid of the first order.
I did not say that catching any exception is stupidity of the first order. I SAID (and you even quote it!) "Wrapping every new in a try/catch would be stupidity of the first order."
Please have the courtesy to respond to what I actually said, not some perversion of my words. Of course you need to catch exceptions, but not necessarily close to the point of throw. In fact, I said "By implementing the strong guarantee, you make life much easier for those few, strategically placed, catch blocks that try to take sensible action after failure." Note that that sentence implies the need for try/catch statements in the code. Just not around every "new". And not in sample code posted on this board, unless illustrating a point about them.
Drivel. They are designed for situations that could possibly happen, but should not occur under normal situations (e.g. running out of memory). A bit like the airbag in a car: hopefully you'll go through life without ever having one explode in your face.Quote:
By its original intention, exceptions are designed for such error condition that is never expected in the first place
If, as you say, exceptions were designed for error conditions that were never expected --- how on earth do you generate one? If you don't expect it, how can you cater for it - by ANY mechanism?
Specific examples, please? As I said, this is misuse of exceptions. If lots of people do it, that doesn't make them right, it just means that lots of people are doing it wrong.Quote:
But since its invention, exceptions is so wide-spread today that it is used daily to return perfectly normal and expected error conditions, or even further, even if the condition is not an error, but merely some thing undesirable, one would thrown an exception, too. If a user inserts CD #2 instead of #1 as requested, an exception is thrown.
More drivel. The moment you specify a particular value for an error return you "clearly indicate that you know something COULD go wrong and you EXPECTED that to happen." The point about an exception is that I know something COULD go wrong, but I DON'T expect it to happen, except in exceptional circumstances."Quote:
The moment you write the "throw" down, you clearly indicate that you know some thing COULD go wrong and you EXPECTED that to happen. So it is no longer an exceptional condition.
Finally - I can add throw() to a function specification: that is a guarantee that no exceptions will propagate out of that function. The fact is, you can add an exception contract to everything that you write: it's just that the consequences of making a misleading claim are pretty dire. (And, yes, I know that that last statement is just going to be grist to your mill, but frankly I don't give a monkey's.)