Re: is such exception handling approach good?

Tech-Archive recommends: Fix windows errors by optimizing your registry

George schrieb:
Thanks Norbert,

Looks like you have better ideas to handle the case when there are exceptions in destructor. Cool!

No, you misunderstood me, I guess I was not clerar enough.
The rule stands: Don't throw exceptions in destructors.
If there are cases where fstream::close might throw an exception then make sure you do not call close when one of the conditions is true. Or do not call close at all in the destructor. I'd hope that fstream's destructor does the required cleanup work without throwing. However, I do not know if the standard library class' destructors are generally guaranteed not to throw.


But I do not 100% understand. :-)

For this case,

* Avoid using new/delete for arrays. Use std::vector<> instead.

Why using vector is better? Because vector does not leak any resources even if there are exceptions? Could you provide more descriptions please?

The point is that std::vector takes care of its memory. You can of course use new/delete in your class and be safe as well. But this requirews great care when implementing the class. You must make sure that for every member pointer you have you set it to 0 or allocate memory in all constructors and call delete in the destructor. You always have the risc that you forget one when adding or removing members during the development phase.
If you always use smart pointers or std containers, you know you are always clean without any additinal thinking.


(I think you mean if we use new, and we may have exceptions when using delete, and such exception will cause memory not fully freed and will cause potential memory leak?) Right?

no, using std::vector instead of new does not solve this issue. It just makes it implssible to forget to call delete in the destructor.

Norbert
.

Relevant Pages

  • Re: New/delete vs. declare/garbage-collect
    ... If the CreateEvent fails in the constructor, ... compiler will begin stack unwinding, and call your destructor. ... whatsoever, then disable exceptions. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: is such exception handling approach good?
    ... exceptions in destructor. ... and such exception will cause memory not fully freed and will cause ... destructor. ... Avoid the use of raw pointers to hold memory. ...
    (microsoft.public.vc.language)
  • Re: C++0x atomic and reference counter
    ... you opt for low-level ordering constraints then you have to specify ... as they cannot legally access the memory locations. ... Does it matter if the destructor is empty as in the example provided? ... and thus needs the acquire fence. ...
    (comp.programming.threads)
  • Re: Returning an unknown number of types/values
    ... >>second is freeing the memory. ... the object's destructor won't be called automatically. ... > works fine with and empty derived destructor as far as I can see. ... That gives us a pointer to buf_. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Virtual dtor and placement new.
    ... // Basically calls the destructor. ... It is possible to store this information in a smart-pointer, ... additional cleanup when the memory is to be deleted (i.e. this functor ...
    (comp.lang.cpp)