Printable View
Hi,
When i am trying to run the code below,it gives runtime<br>
exception. Although i am ctching the exception.<br>
Plz suggest something. I cann't check the pointer against<br>
NULL.
Regards<br>Code:#include<iostream>
#include<stdexcept>
using namespace std;
void main()
{
char* p;
try
{
delete p;
}
catch(exception ex)
{
cout<<"hello"<<endl;
}
}
Ram
You've not allocated anything with new.Quote:
Originally posted by Ram_Gupta
Hi,
When i am trying to run the code below,it gives runtime<br>
exception. Although i am ctching the exception.<br>
Plz suggest something. I cann't check the pointer against<br>
NULL.
Regards<br>Code:#include<iostream>
#include<stdexcept>
using namespace std;
void main()
{
char* p;
try
{
delete p;
}
catch(exception ex)
{
cout<<"hello"<<endl;
}
}
Ram
try:
Code:char* p = new char[100];
delete[] p;
Hi,
I agree with u. Actually it was a test code. In original one
class is having some pointer data member. In the destructor
he is freeing the memory but doesn't assign the pointer to
NULL. So somehow he has assigned the object to someone
else, so that pointer has become a dangling one. I don't
want to change his overloaded = oparetor nor do i wanna
provide a copy ctor. So i wanna call delete, catch the exception
and cooly come out without any runtime error.
Thanx and Regards
Ram
Why do you want to call delete on something that you know is a "dangling pointer"?Quote:
Originally posted by Ram_Gupta
Hi,
I agree with u. Actually it was a test code. In original one
class is having some pointer data member. In the destructor
he is freeing the memory but doesn't assign the pointer to
NULL. So somehow he has assigned the object to someone
else, so that pointer has become a dangling one. I don't
want to change his overloaded = oparetor nor do i wanna
provide a copy ctor. So i wanna call delete, catch the exception
and cooly come out without any runtime error.
Thanx and Regards
Ram
Just to recap: the example code given by the OP invokes undefined behaviour, since the delete is called on a pointer that has not been allocated by new and it is not NULL.
Hi,
I just want to know whether i can catch an exception
if call delete on dangling pointer. B'coz in that case my
job would be less tiresome.
Thakx and Regards
Ram.
Yes.Quote:
Originally posted by Ram_Gupta
Hi,
I just want to know whether i can catch an exception
if call delete on dangling pointer. B'coz in that case my
job would be less tiresome.
Thakx and Regards
Ram.
You can catch the exception.
To reiterate:
It is undefined behaviour
This means that, just because this particular compiler (or version of the compiler) throws an exception, you can't rely on that. The next upgrade to your compiler may do something different. For example, it may just call exit() immediately. It might reboot your machine or reformat the hard disk: it could do anything: that's what undefined behaviour means.
Fix the problem, don't try to patch it over. Your desire not to provide a copy ctor is unreasonable. Do a deep copy, not a shallow one; implement a reference counted smart pointer if you don't want a deep copy, but do something positive to address the problem, rather than rely on behaviour that is intrinsically unreliable.
Hi,
I am trying my best to trace the actual problem. Out of curosity
i just wanna experiment that. But the code above is still
throwing runtime error dialog box...that means it's not going
into the catch block.
Thanx and Regards
Ram.
Right. You're catching the wrong type of exception. I didn't indicate which "type" of exception to catch, because of the reasons Graham stated. You asked if something is possible. Yes, it is possible. Don't rely on it. Fix the problem "the right way" - Graham offered several suggestions. Abandon the path you seem to be headed down.Quote:
Originally posted by Ram_Gupta
Hi,
I am trying my best to trace the actual problem. Out of curosity
i just wanna experiment that. But the code above is still
throwing runtime error dialog box...that means it's not going
into the catch block.
Thanx and Regards
Ram.
void main()??? That speaks levels...
What complier are you using and what platform are you running under. Regardless if the question/behaviour is undefined as indicated.
Hi,
Can u tell me which exception i should catch?
Thankx and Regards
Ram
You shouldn't be catching any exceptions, you should be fixing the underlying problem!
As others have indicated and I'll say so too, the behaviour is undefined, but under WinDoze it would be a SException presumably of type access violation, if one occurred, and that's a crap shoot on where in your prog you might encounter one, since your freeing memory that may be in use somewhere else in your program.Quote:
Originally posted by Ram_Gupta
Hi,
Can u tell me which exception i should catch?
Thankx and Regards
Ram
There is a couple of underlying issues.
1. whatever complier your using should catch this, and issue a warning about using an uinit'd var.
2. The debug build of your particular memory management routines should catch this also.
3. it's undefined because it all depends ;) I can't imagine 1 and 2 not occuring
so your code should never be getting into the field with this type of error.
Aside from fully agreeing with the previous posters, you can catch Windows SEH exceptions with
catch(...)
but you don't know what hit you.
is there some clearance sell on SExceptions today??? just in time for christmas??? This must make my 6th comment on it today...Quote:
Originally posted by CornedBee
Aside from fully agreeing with the previous posters, you can catch Windows SEH exceptions with
catch(...)
but you don't know what hit you.
install a set_se_translator(...) re-throw, after a stackwalk(...) if you like...your catch(...) becomes catch(unsigned int foo)
And you don't know what state your process or thread is in. Did the thread have a stack overflow? Are you sure you can recover? Was there a privileged instruction? Did the thread forget to release a mutex in the stack-unwinding? etc...Quote:
Originally posted by CornedBee
Aside from fully agreeing with the previous posters, you can catch Windows SEH exceptions with
catch(...)
but you don't know what hit you.
All of which brings us back to: fix the underlying problem. ;)
Yep. Oh, and stack overflows cannot be caught that way.
Incorrect.Quote:
Originally posted by CornedBee
Yep. Oh, and stack overflows cannot be caught that way.
An exception 0xc00000fd sure can be caught by "catch( ... )" or by using structured exception handling via set_se_translator...
Right. Hmm, I was sure that I remembered something written about stack overflows immediatly and irrecoverably terminating the application.
Well... if you don't catch it... :)Quote:
Originally posted by CornedBee
Right. Hmm, I was sure that I remembered something written about stack overflows immediatly and irrecoverably terminating the application.
Anyone catching an "exception" that results from undefined behaviour including platform-specific failures (such as a stack overflow), really needs to hit the (C++) books again.Quote:
Originally posted by vicodin451
Incorrect.
An exception 0xc00000fd sure can be caught by "catch( ... )" or by using structured exception handling via set_se_translator...
The "void main()" is a typically a giveaway that though this is the non-VC++ forum, the OP is using VC++. The talk of structured exceptions is of course Windows-specific.Quote:
Originally posted by Sef
Anyone catching an "exception" that results from undefined behaviour including platform-specific failures (such as a stack overflow), really needs to hit the (C++) books again.
IIRC, Richter details an example of catching a stack overflow and recovering from it in "Programming Applications for Microsoft Windows".
At any rate, if you will follow this thread, you will see that it was not recommended that the OP do anything along the lines of catching any sort of "exception" caused by "undefined behavior". The OP was urged to correct the problem rather than hide its effects.