Exception in Constructor

[TarheelsFan]

What happens whenever you throw an exception from within a constructor?
Does the object just not get instantiated?

Thanks for replies.

[Bruce Wood]

On Jan 24, 12:40 pm, "TarheelsFa n" <tsedw...@winga te.eduwrote:

What happens whenever you throw an exception from within a constructor?
Does the object just not get instantiated?

Thanks for replies.

Well, the object certainly gets created on the heap, but once the
constructor exits with an exception you have no way of getting at the
instantiated object.

The object is surely allocated, because the constructor is supposed to
fill it in. So, before the constructor is called there is memory
allocated for the instance. If the constructor fails, the memory just
doesn't finish getting filled with values.

However, since the constructor throws an exception, any reference
variable where you were hoping to assign the instance reference will
remain uninintialized. So, for example, if you say

Person p = new Person("Harry") ;

then after the exception, p will remain uninitialized, because the
constructor never finished its job.

The orphaned memory will then be cleaned up by the Garbage Collector.

[Ben Voigt]

"TarheelsFa n" <ts******@winga te.eduwrote in message
news:11******** **************@ a75g2000cwd.goo glegroups.com.. .

What happens whenever you throw an exception from within a constructor?
Does the object just not get instantiated?

(1) The object doesn't get instantiated, so I think its finalizer won't ever
run.
(2) Whoever tried to create an instance has to deal with the exception.
(3) As Bruce said, since the exception breaks you out of the try block that
would have assigned a reference to the new object, it's unrooted. The GC
will reclaim the memory, along with any objects only reachable from the
aborted construction. I think that if those objects were constructed fully,
their finalizers will run. If such subobjects need to be disposed, then
your constructor should do that before throwing the exception, because
otherwise. Of course, any changes you made to global program state before
throwing will be visible.

I don't know what happens if the constructor saved the this reference in
another object. It would be worth a try to investigate that. For example:

class Ugly
{
public static Ugly Singleton = null;
public Ugly()
{
Singleton = this; // The Spec# compiler won't let you, because
this isn't fully constructed yet
throw new NotImplementedE xception();
}
static void Main()
{
try {
Ugly stepsister = new Ugly();
}
catch (Exception) {}
// do something with Singleton???
}
}

>
Thanks for replies.

[Ben Voigt]

"Ben Voigt" <rb*@nospam.nos pamwrote in message
news:uA******** ******@TK2MSFTN GP06.phx.gbl...

>
"TarheelsFa n" <ts******@winga te.eduwrote in message
news:11******** **************@ a75g2000cwd.goo glegroups.com.. .

>What happens whenever you throw an exception from within a constructor?
Does the object just not get instantiated?

I'm horribly wrong:

(1) The object doesn't get instantiated, so I think its finalizer won't
ever run.

The object IS instantiated as of the moment the user-defined starts running,
which is incidentally the first place you can use the this pointer (unless
you had inheritance, I see an even more evil example coming up). The
finalizer IS run.

(2) Whoever tried to create an instance has to deal with the exception.

Just like C++ two-phase construction. The caller's assignment of the
constructed object can't happen, because it's necessarily inside the try
block being exited, but the instance can be referenced elsewhere.
public class Ugly : IDisposable
{
public static Ugly Singleton;
public Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.ctor");
Singleton = this;
throw new NotImplementedE xception();
}
~Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.dtor");
}
public void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Ugly::Dispose") ;
}
public static void Main()
{
try
{
Ugly stepsister = new Ugly();
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("first " +
Ugly.Singleton. ToString());
try
{
using (Ugly stepsister = new Ugly()) { }
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("second " +
Ugly.Singleton. ToString());
}
}
in Ugly::.ctor
A first chance exception of type 'System.NotImpl ementedExceptio n' occurred
in UselessJunkForD issassembly.exe
first UselessJunkForD issassembly.Ugl y
in Ugly::.ctor
A first chance exception of type 'System.NotImpl ementedExceptio n' occurred
in UselessJunkForD issassembly.exe
second UselessJunkForD issassembly.Ugl y
The thread 0xfc4 has exited with code 0 (0x0).
The thread 0xf3c has exited with code 0 (0x0).
in Ugly::.dtor
in Ugly::.dtor

[Ben Voigt]

Well, apparently the most-derived object is already alive before *any* user
constructor code starts running. It's effectively the same as two-phase
construction. This lets you call virtual methods virtually from the
constructor I guess, don't let your virtual methods rely on the constructor
previously running:
public abstract class Ugly : IDisposable
{
public static Ugly Singleton;
public Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.ctor");
Singleton = this;
throw new NotImplementedE xception();
}
~Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.dtor");
}
public virtual void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Ugly::Dispose") ;
}
public static void Main()
{
try
{
Ugly stepsister = new Uglier();
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("first " +
Ugly.Singleton. ToString());
try
{
using (Ugly stepsister = new Uglier()) { }
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("second " +
Ugly.Singleton. ToString());
}
}

public class Uglier : Ugly, IDisposable
{
public Uglier()
: base()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.ctor") ;
Singleton = this;
throw new NotImplementedE xception();
}
~Uglier()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.dtor") ;
}
public override void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Uglier::Dispose ");
}
}

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n' occurred
in UselessJunkForD issassembly.exe

first UselessJunkForD issassembly.Ugl ier

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n' occurred
in UselessJunkForD issassembly.exe

second UselessJunkForD issassembly.Ugl ier

The thread 0x9bc has exited with code 0 (0x0).

The thread 0xe80 has exited with code 0 (0x0).

in Uglier::.dtor

in Ugly::.dtor

in Uglier::.dtor

in Ugly::.dtor

[Dave Sexton]

Hi Ben,

This lets you call virtual methods virtually from the constructor I guess

You shouldn't call virtual methods from within the constructor since the
constructor of derived classes will not have executed yet even though it may
be the derived method that's invoked.

--
Dave Sexton
http://davesexton.com/blog
http://www.codeplex.com/DocProject (Sandcastle in VS IDE)

"Ben Voigt" <rb*@nospam.nos pamwrote in message
news:eY******** ******@TK2MSFTN GP04.phx.gbl...

Well, apparently the most-derived object is already alive before *any*
user constructor code starts running. It's effectively the same as
two-phase construction. This lets you call virtual methods virtually from
the constructor I guess, don't let your virtual methods rely on the
constructor previously running:
public abstract class Ugly : IDisposable
{
public static Ugly Singleton;
public Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.ctor");
Singleton = this;
throw new NotImplementedE xception();
}
~Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.dtor");
}
public virtual void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Ugly::Dispose") ;
}
public static void Main()
{
try
{
Ugly stepsister = new Uglier();
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("first " +
Ugly.Singleton. ToString());
try
{
using (Ugly stepsister = new Uglier()) { }
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("second " +
Ugly.Singleton. ToString());
}
}

public class Uglier : Ugly, IDisposable
{
public Uglier()
: base()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.ctor") ;
Singleton = this;
throw new NotImplementedE xception();
}
~Uglier()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.dtor") ;
}
public override void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Uglier::Dispose ");
}
}

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n' occurred
in UselessJunkForD issassembly.exe

first UselessJunkForD issassembly.Ugl ier

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n' occurred
in UselessJunkForD issassembly.exe

second UselessJunkForD issassembly.Ugl ier

The thread 0x9bc has exited with code 0 (0x0).

The thread 0xe80 has exited with code 0 (0x0).

in Uglier::.dtor

in Ugly::.dtor

in Uglier::.dtor

in Ugly::.dtor

[Ben Voigt]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:Ox******** ******@TK2MSFTN GP04.phx.gbl...

Hi Ben,

> This lets you call virtual methods virtually from the constructor I
guess

You shouldn't call virtual methods from within the constructor since the
constructor of derived classes will not have executed yet even though it
may be the derived method that's invoked.

I agree that you shouldn't call (any) methods from a constructor without
documenting that fact. I can definitely see where it would have its uses
though. I think this is very different from C++ though, because I think in
C++ the v-table doesn't hold the members in the derived class until the
derived constructor starts.

It would be interesting to find out what order field initializers are run...
are derived class fields using initializer syntax initialized before the
base constructor runs?

>
--
Dave Sexton
http://davesexton.com/blog
http://www.codeplex.com/DocProject (Sandcastle in VS IDE)

"Ben Voigt" <rb*@nospam.nos pamwrote in message
news:eY******** ******@TK2MSFTN GP04.phx.gbl...

>Well, apparently the most-derived object is already alive before *any*
user constructor code starts running. It's effectively the same as
two-phase construction. This lets you call virtual methods virtually
from the constructor I guess, don't let your virtual methods rely on the
constructor previously running:
public abstract class Ugly : IDisposable
{
public static Ugly Singleton;
public Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.ctor");
Singleton = this;
throw new NotImplementedE xception();
}
~Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.dtor");
}
public virtual void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Ugly::Dispose") ;
}
public static void Main()
{
try
{
Ugly stepsister = new Uglier();
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("first " +
Ugly.Singleton .ToString());
try
{
using (Ugly stepsister = new Uglier()) { }
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("second " +
Ugly.Singleton .ToString());
}
}

public class Uglier : Ugly, IDisposable
{
public Uglier()
: base()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.ctor") ;
Singleton = this;
throw new NotImplementedE xception();
}
~Uglier()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.dtor") ;
}
public override void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Uglier::Dispose ");
}
}

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n'
occurred in UselessJunkForD issassembly.exe

first UselessJunkForD issassembly.Ugl ier

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n'
occurred in UselessJunkForD issassembly.exe

second UselessJunkForD issassembly.Ugl ier

The thread 0x9bc has exited with code 0 (0x0).

The thread 0xe80 has exited with code 0 (0x0).

in Uglier::.dtor

in Ugly::.dtor

in Uglier::.dtor

in Ugly::.dtor

[Dave Sexton]

Hi Ben,

The problem with calling a virtual method from a constructor is that fields
in the derived class might not be initialized before the override is called:

Visual Studio Team System
Do not call overridable methods in constructors
http://msdn2.microsoft.com/en-us/lib...31(VS.80).aspx

--
Dave Sexton
http://davesexton.com/blog
http://www.codeplex.com/DocProject (Sandcastle in VS IDE)

"Ben Voigt" <rb*@nospam.nos pamwrote in message
news:uk******** ********@TK2MSF TNGP06.phx.gbl. ..

>
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:Ox******** ******@TK2MSFTN GP04.phx.gbl...

>Hi Ben,

>> This lets you call virtual methods virtually from the constructor I
guess

You shouldn't call virtual methods from within the constructor since the
constructor of derived classes will not have executed yet even though it
may be the derived method that's invoked.

I agree that you shouldn't call (any) methods from a constructor without
documenting that fact. I can definitely see where it would have its uses
though. I think this is very different from C++ though, because I think
in C++ the v-table doesn't hold the members in the derived class until the
derived constructor starts.

It would be interesting to find out what order field initializers are
run... are derived class fields using initializer syntax initialized
before the base constructor runs?

>>
--
Dave Sexton
http://davesexton.com/blog
http://www.codeplex.com/DocProject (Sandcastle in VS IDE)

"Ben Voigt" <rb*@nospam.nos pamwrote in message
news:eY******* *******@TK2MSFT NGP04.phx.gbl.. .

>>Well, apparently the most-derived object is already alive before *any*
user constructor code starts running. It's effectively the same as
two-phase construction. This lets you call virtual methods virtually
from the constructor I guess, don't let your virtual methods rely on the
constructor previously running:
public abstract class Ugly : IDisposable
{
public static Ugly Singleton;
public Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.ctor");
Singleton = this;
throw new NotImplementedE xception();
}
~Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.dtor");
}
public virtual void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Ugly::Dispose") ;
}
public static void Main()
{
try
{
Ugly stepsister = new Uglier();
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("first " +
Ugly.Singleto n.ToString());
try
{
using (Ugly stepsister = new Uglier()) { }
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("second " +
Ugly.Singleto n.ToString());
}
}

public class Uglier : Ugly, IDisposable
{
public Uglier()
: base()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.ctor") ;
Singleton = this;
throw new NotImplementedE xception();
}
~Uglier()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.dtor") ;
}
public override void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Uglier::Dispose ");
}
}

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n'
occurred in UselessJunkForD issassembly.exe

first UselessJunkForD issassembly.Ugl ier

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n'
occurred in UselessJunkForD issassembly.exe

second UselessJunkForD issassembly.Ugl ier

The thread 0x9bc has exited with code 0 (0x0).

The thread 0xe80 has exited with code 0 (0x0).

in Uglier::.dtor

in Ugly::.dtor

in Uglier::.dtor

in Ugly::.dtor

[Jon Skeet [C# MVP]]

Ben Voigt <rb*@nospam.nos pamwrote:

<snip>

It would be interesting to find out what order field initializers are run...
are derived class fields using initializer syntax initialized before the
base constructor runs?

Derived field initializers are called, then the base field
initializers, then the base constructor, then the derived constructor.
Note that this is different to Java, which runs the base constructor
before the field initializers.

See http://www.yoda.arachsys.com/csharp/constructors.html for more
information.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Ben Voigt]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..

Hi Ben,

The problem with calling a virtual method from a constructor is that
fields

It's not a "problem", its documented, reliable behavior that has to be
considered in the design. Drawback perhaps, but not exactly a problem.

in the derived class might not be initialized before the override is
called:

Visual Studio Team System
Do not call overridable methods in constructors
http://msdn2.microsoft.com/en-us/lib...31(VS.80).aspx

--
Dave Sexton
http://davesexton.com/blog
http://www.codeplex.com/DocProject (Sandcastle in VS IDE)

"Ben Voigt" <rb*@nospam.nos pamwrote in message
news:uk******** ********@TK2MSF TNGP06.phx.gbl. ..

>>
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:Ox******* *******@TK2MSFT NGP04.phx.gbl.. .

>>Hi Ben,

This lets you call virtual methods virtually from the constructor I
guess

You shouldn't call virtual methods from within the constructor since the
constructor of derived classes will not have executed yet even though it
may be the derived method that's invoked.

I agree that you shouldn't call (any) methods from a constructor without
documenting that fact. I can definitely see where it would have its uses
though. I think this is very different from C++ though, because I think
in C++ the v-table doesn't hold the members in the derived class until
the derived constructor starts.

It would be interesting to find out what order field initializers are
run... are derived class fields using initializer syntax initialized
before the base constructor runs?

>>>
--
Dave Sexton
http://davesexton.com/blog
http://www.codeplex.com/DocProject (Sandcastle in VS IDE)

"Ben Voigt" <rb*@nospam.nos pamwrote in message
news:eY****** ********@TK2MSF TNGP04.phx.gbl. ..
Well, apparently the most-derived object is already alive before *any*
user constructor code starts running. It's effectively the same as
two-phase construction. This lets you call virtual methods virtually
from the constructor I guess, don't let your virtual methods rely on
the constructor previously running:
public abstract class Ugly : IDisposable
{
public static Ugly Singleton;
public Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.ctor");
Singleton = this;
throw new NotImplementedE xception();
}
~Ugly()
{
System.Diagnost ics.Trace.Write Line("in Ugly::.dtor");
}
public virtual void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Ugly::Dispose") ;
}
public static void Main()
{
try
{
Ugly stepsister = new Uglier();
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("first " +
Ugly.Singlet on.ToString());
try
{
using (Ugly stepsister = new Uglier()) { }
}
catch (Exception) { }
System.Diagnost ics.Trace.Write Line("second " +
Ugly.Singlet on.ToString());
}
}

public class Uglier : Ugly, IDisposable
{
public Uglier()
: base()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.ctor") ;
Singleton = this;
throw new NotImplementedE xception();
}
~Uglier()
{
System.Diagnost ics.Trace.Write Line("in Uglier::.dtor") ;
}
public override void Dispose()
{
System.Diagnost ics.Trace.Write Line("in Uglier::Dispose ");
}
}

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n'
occurred in UselessJunkForD issassembly.exe

first UselessJunkForD issassembly.Ugl ier

in Ugly::.ctor

A first chance exception of type 'System.NotImpl ementedExceptio n'
occurred in UselessJunkForD issassembly.exe

second UselessJunkForD issassembly.Ugl ier

The thread 0x9bc has exited with code 0 (0x0).

The thread 0xe80 has exited with code 0 (0x0).

in Uglier::.dtor

in Ugly::.dtor

in Uglier::.dtor

in Ugly::.dtor