you can use _finally (C++) or finally (C#) blocks to make sure that no
memory leaks happen.see the
following code:
Class1* c = NULL;
try {
c = new Class1();
c.DoSomething();
}
catch {char* msg) {}
finally
{
if (c==Null)
{
if ( _myIntPointer!=NULL)
{
delete _myIntPointer;
}
}
}
if (c != NULL) delete c;
Note that _finally(C++) or finally(C#) block is only supported for managed
code.
Muhammad Adel
"The secret to creativity is knowing how to hide your sources". Einstein
----- Original Message -----
From: "Chad M. Gross" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 31, 2004 11:23 PM
Subject: Re: [ADVANCED-DOTNET] Exceptions in Constructors
Chris,
Your brain was hammered appropriately. Say in C++ you had a class called
Class1 that had a private field member int* _myIntPointer. In your
constructor you intending on initializing the pointer to something using
the new operator and cleaning up after yourself in the destructor
using "if (_myIntPointer != NULL) delete _myIntPointer". In your main
program you have some usage like:
Class1* c = NULL;
try {
c = new Class1();
c.DoSomething();
}
catch {char* msg) {}
if (c != NULL) delete c;
The problem would be that if in your constructor of Class1, after
initializing the _myIntPointer, you encountered an unhandled exception (or
raised one), you would have a memory leak with no way to clean up
_myIntPointer because
the Class1* variable c would be a null reference (because of the exception
in the constructor) with no way to call delete c in order to have your
destructor fire (which was going to clean up _myIntPointer).
Just like in C++, if in .NET you created an object with the new operator
and an exception is thorwn in the constructor, your object reference will
be null. But it's not really that .NET handles constructors differently,
it's that the runtime manages/tracks memory allocated and cleans up behind
you through garbage collection.
As for whether it's acceptable to throw exceptions in constructors, I can
say I am guilty. It is sometimes much easier to blow up in a constructor
if you already know that the context in which the object being used is not
acceptable. Otherwise, you would have to put a call to some validation
routine on every public method to determine if everything is OK and then
raise that same exception you would have thrown in the constructor. One
down side to throwing errors in constructors I guess would be that you may
expect that a simple Class1 c = new Class1() would always suceed and not
put it inside of a try/catch block.
Chad
On Wed, 31 Mar 2004 09:29:57 -0500, Chris Snyder
<[EMAIL PROTECTED]> wrote:
>I have a (hopefully) simple question.
>
>In a nutshell, as a C++ developer, various people hammered into my brain
>that throwing an exception in a constructor (whether intentionally or by
>performing some action which would cause an exception to be thrown) was
>extremely bad. However, my research seems to indicate that .NET handles
>constructors differently, allowing developers to perform actions in a
>constructor that may result in exceptions being thrown, or to <gasp> even
>throw an exception themselves.
>
>Thoughts?
>
>Thanks a lot,
>Chris Snyder
>
>===================================
>This list is hosted by DevelopMentorŪ http://www.develop.com
>Some .NET courses you may be interested in:
>
>NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
>http://www.develop.com/courses/gaspdotnetls
>
>View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
