Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > What if new throws exeption?

Reply
Thread Tools

What if new throws exeption?

 
 
doublemaster007@gmail.com
Guest
Posts: n/a
 
      12-17-2009
Hi All

somePtr *obj =NULL; ----------------------------(1)
obj = new somePtr; -----------------------------(2)

if(obj!=NULL) ------------------------------(3)
{
//do somthing
}

Is this code correct?
first, "new" doesnt return NULL. I have read this some where. Or is
that (1) ensures obj NULL after (2)
AFAIK, new throws exeption. So will the (3) be exexuted?

Reason i am asking this is, Its become a practise that checking for
NULL instead of trying for exeption. Is the above code really correct?

One more question. If new fails, Do we need to call the destructor of
obj explicitly?? AFAIK objected isnt contructed so we donot need to
call destructor..am i right???
 
Reply With Quote
 
 
 
 
Kenshin
Guest
Posts: n/a
 
      12-17-2009
On Dec 17, 8:58*am, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> Hi All
>
> somePtr *obj =NULL; * * * * * *----------------------------(1)
> obj = new somePtr; * * * * * * *-----------------------------(2)
>
> if(obj!=NULL) * * * * * * * * * * * ------------------------------(3)
> {
> *//do somthing
>
> }
>
> Is this code correct?
> first, "new" doesnt return NULL. I have read this some where. Or is
> that *(1) ensures obj NULL after (2)
> AFAIK, new throws exeption. So will the (3) be exexuted?
>
> Reason i am asking this is, Its become a practise that checking for
> NULL instead of trying for exeption. Is the above code really correct?
>
> One more question. If new fails, Do we need to call the destructor of
> obj explicitly?? *AFAIK objected isnt contructed so we donot need to
> call destructor..am i right???


And herein is the power of smart pointers made manifest:

std::scoped_ptr<somePtr> obj(new somePtr);

if(obj){

 
Reply With Quote
 
 
 
 
Vladimir Jovic
Guest
Posts: n/a
 
      12-17-2009
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hi All
>
> somePtr *obj =NULL; ----------------------------(1)
> obj = new somePtr; -----------------------------(2)
>
> if(obj!=NULL) ------------------------------(3)
> {
> //do somthing
> }
>
> Is this code correct?


Maybe. I can not compile it. See this:
http://www.parashift.com/c++-faq-lit...t.html#faq-5.8

> first, "new" doesnt return NULL. I have read this some where. Or is
> that (1) ensures obj NULL after (2)
> AFAIK, new throws exeption. So will the (3) be exexuted?


If (2) throws an exception, then (3) will not be executed.

>
> Reason i am asking this is, Its become a practise that checking for
> NULL instead of trying for exeption. Is the above code really correct?
>


That practice is for C, not for c++. In c++ you check for the exception.

> One more question. If new fails, Do we need to call the destructor of
> obj explicitly?? AFAIK objected isnt contructed so we donot need to
> call destructor..am i right???


No and yes.
1) No - for call the destructor. In 99.999% cases you do not need to
call destructor explicitly. Specially in this case
2) Yes - you are right

--
ultrasound www.ezono.com
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      12-17-2009
On Dec 17, 5:58 am, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:

> somePtr *obj =NULL; ----------------------------(1)
> obj = new somePtr; -----------------------------(2)


> if(obj!=NULL) ------------------------------(3)
> {
> //do somthing
> }


> Is this code correct?


In what sense? It's certainly legal. If there's nothing between (2)
and (3), however, the if is guaranteed to be true.

> first, "new" doesnt return NULL. I have read this some where. Or is
> that (1) ensures obj NULL after (2) AFAIK, new throws exeption. So
> will the (3) be exexuted?


More context is needed. There are definitely cases where something
like:

SomeType* obj = NULL;
try {
obj = new SomeType;
// ... do something with obj...
} catch (...) {
// do something else...
}
// obj is still in scope here...
delete obj;

but they aren't frequent. (At all, in fact. I'd qualify them as
rare.)

> Reason i am asking this is, Its become a practise that checking for
> NULL instead of trying for exeption. Is the above code really correct?


You don't check for null after new, and you don't "try for an
exception": you get an exception if there is not enough memory (unless
you've set the new_handler to do something else, like abort), and your
code should be able to deal with it.

> One more question. If new fails, Do we need to call the destructor of
> obj explicitly?? AFAIK objected isnt contructed so we donot need to
> call destructor..am i right???


Obviously. The constructor can't be called until the memory is
allocated. If allocation fails, the constructor is never called.

--
James Kanze
 
Reply With Quote
 
Vladimir Jovic
Guest
Posts: n/a
 
      12-17-2009
Kenshin wrote:
> And herein is the power of smart pointers made manifest:
>
> std::scoped_ptr<somePtr> obj(new somePtr);
>
> if(obj){
>


Can you explain how the power of smart pointers is manifested in your
code snippet? The "if" statement will not be executed.

--
ultrasound www.ezono.com
 
Reply With Quote
 
Kenshin
Guest
Posts: n/a
 
      12-17-2009
On Dec 17, 8:58*am, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> Hi All
>
> somePtr *obj =NULL; * * * * * *----------------------------(1)
> obj = new somePtr; * * * * * * *-----------------------------(2)
>
> if(obj!=NULL) * * * * * * * * * * * ------------------------------(3)
> {
> *//do somthing
>
> }
>
> Is this code correct?
> first, "new" doesnt return NULL. I have read this some where. Or is
> that *(1) ensures obj NULL after (2)
> AFAIK, new throws exeption. So will the (3) be exexuted?
>
> Reason i am asking this is, Its become a practise that checking for
> NULL instead of trying for exeption. Is the above code really correct?
>
> One more question. If new fails, Do we need to call the destructor of
> obj explicitly?? *AFAIK objected isnt contructed so we donot need to
> call destructor..am i right???


And herein is the power of smart pointers made manifest:

//BEGINNINOF SOME SCOPE//

std::unique_ptr<somePtr> obj(new somePtr);

if(obj){

obj->call_method(); //use as though raw pointer//
function(obj.get()/*, other_arguments */); //function takes raw
pointer, so obj.get() returns contained pointer//

}

return obj.release(); //relinquishes ownership of raw pointer, better
to return smart pointer//

//END OF SOME SCOPE// //raw pointer automatically deleted//

The smart pointer (auto (avoid), scoped, unique, shared, weak) takes
care of all your worries, or at least 99% (keeping in mind the pitfall
of using shared pointer temporaries).
 
Reply With Quote
 
Vladimir Jovic
Guest
Posts: n/a
 
      12-17-2009
James Kanze wrote:
>
> You don't check for null after new, and you don't "try for an
> exception": you get an exception if there is not enough memory (unless
> you've set the new_handler to do something else, like abort), and your
> code should be able to deal with it.
>


What I thought is this :
In the end (somewhere in main()), you should check for std::bad_alloc or
std::exception, and log the error/inform the user, and clean up nicely.
Instead of just letting the exception kill your program.
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      12-17-2009
Vladimir Jovic wrote:

> James Kanze wrote:
>>
>> You don't check for null after new, and you don't "try for an
>> exception": you get an exception if there is not enough memory (unless
>> you've set the new_handler to do something else, like abort), and your
>> code should be able to deal with it.
>>

>
> What I thought is this :
> In the end (somewhere in main()), you should check for std::bad_alloc or
> std::exception, and log the error/inform the user, and clean up nicely.
> Instead of just letting the exception kill your program.


A good compiler will already provide that, including more information than
you can get in a standard C++ program, like e.g. a backtrace.

 
Reply With Quote
 
Vladimir Jovic
Guest
Posts: n/a
 
      12-17-2009
Rolf Magnus wrote:
> Vladimir Jovic wrote:
>
>> James Kanze wrote:
>>> You don't check for null after new, and you don't "try for an
>>> exception": you get an exception if there is not enough memory (unless
>>> you've set the new_handler to do something else, like abort), and your
>>> code should be able to deal with it.
>>>

>> What I thought is this :
>> In the end (somewhere in main()), you should check for std::bad_alloc or
>> std::exception, and log the error/inform the user, and clean up nicely.
>> Instead of just letting the exception kill your program.

>
> A good compiler will already provide that, including more information than
> you can get in a standard C++ program, like e.g. a backtrace.
>



void a()
{
int *p = new int[1000000];
}
void b()
{
for(int i=0; i<1000000;++i)
{
int *a = new int[1000000];
}
}
int main()
{
a();
b();
}


This example gives just this:

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted

I compiled the example using g++ 4.3.0, which I find good enough.
 
Reply With Quote
 
John H.
Guest
Posts: n/a
 
      12-17-2009
On Dec 16, 11:58*pm, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> Reason i am asking this is, Its become a practise that checking for
> NULL instead of trying for exeption. Is the above code really correct?


Yes the standard way for new to fail due to lack of memory is to throw
an exception. There was at least one popular C++ compiler (I think
MSVC++ 6.0) that returned a null pointer. In addition, you can get
this behavior in a more standard way by using the no throw new:

#include <new>
int main()
{
double * p = new(std::nothrow) double[99999999];
if(p == NULL)
{
// chance to do some error handling
}
delete[] p;
return 0;
}
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
new throws or returns? Chameleon C++ 6 01-06-2007 04:56 PM
DataInputStream(new GZIPInputStream).readFully throws EOFException A. Farber Java 3 03-21-2006 11:20 AM
Visual Studio throws UnauthorizedAccessException when debugging R Warford ASP .Net 3 12-01-2003 04:08 PM
Web Service throws 401 Error when consumed Sanjay ASP .Net 4 11-20-2003 04:03 AM
XmlValidatingReader throws exception for SAOP-ENV:encodingStyle attribute Himmat Dhange ASP .Net 0 08-26-2003 08:28 PM



Advertisments