What if new throws exeption?

Discussion in 'C++' started by doublemaster007@gmail.com, Dec 17, 2009.

  1. Guest

    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???
     
    , Dec 17, 2009
    #1
    1. Advertising

  2. Kenshin Guest

    On Dec 17, 8:58 am, ""
    <> 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){
     
    Kenshin, Dec 17, 2009
    #2
    1. Advertising

  3. 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-lite/how-to-post.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
     
    Vladimir Jovic, Dec 17, 2009
    #3
  4. James Kanze Guest

    On Dec 17, 5:58 am, ""
    <> 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
     
    James Kanze, Dec 17, 2009
    #4
  5. 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
     
    Vladimir Jovic, Dec 17, 2009
    #5
  6. Kenshin Guest

    On Dec 17, 8:58 am, ""
    <> 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).
     
    Kenshin, Dec 17, 2009
    #6
  7. 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.
     
    Vladimir Jovic, Dec 17, 2009
    #7
  8. Rolf Magnus Guest

    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.
     
    Rolf Magnus, Dec 17, 2009
    #8
  9. 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.
     
    Vladimir Jovic, Dec 17, 2009
    #9
  10. John H. Guest

    On Dec 16, 11:58 pm, ""
    <> 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;
    }
     
    John H., Dec 17, 2009
    #10
  11. James Kanze Guest

    On Dec 17, 11:21 pm, "John H." <> wrote:
    > On Dec 16, 11:58 pm, ""


    > <> 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.


    There *were* a lot of C++ compilers which returned a null pointer.
    Back
    in 1990, when I was learning C++, all of them, in fact.

    What makes VC++ 6.0 special in this regard is that it is still being
    used. This isn't true for any of the other compilers which returned a
    null pointer. (One might ask why it is still being used. Microsoft
    has
    a number of more recent versions, which are not only closer to the
    standard, but fix a number of real bugs.)

    --
    James Kanze
     
    James Kanze, Dec 18, 2009
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ricky K. Rasmussen

    Strange exeption when connecting to WebService

    Ricky K. Rasmussen, Oct 22, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    334
    Steven Cheng[MSFT]
    Oct 25, 2004
  2. ad
    Replies:
    4
    Views:
    935
  3. tshad

    Exeption properties

    tshad, Feb 8, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    340
    tshad
    Feb 8, 2006
  4. Robert Wallström

    System.Directoryservices getting TxIsolationLevel exeption?

    Robert Wallström, Jun 4, 2004, in forum: ASP .Net Security
    Replies:
    5
    Views:
    145
    Joe Kaplan \(MVP - ADSI\)
    Jun 5, 2004
  5. Mikael Boedker
    Replies:
    0
    Views:
    219
    Mikael Boedker
    Aug 18, 2004
Loading...

Share This Page