Constructors, exceptions, and instances.

[Carl Howells]

This is such a bad idea. And yet, it works:

--- code ----
public class Test
{
private int b;

public Test(int a) throws Test.HoldingException
{
b = a;
throw new HoldingException(this);
}

public static void main(String [] args)
{
try
{
Test s = new Test(10);
}
catch (Test.HoldingException e)
{
Test s = (Test)e.getHeld();
System.out.println(s.toString() + " " + s.b);
}
}

private static class HoldingException extends Exception
{
Object held;

public HoldingException(Object o)
{
held = o;
}

public Object getHeld()
{
return held;
}
}
}
--- code ----

I'm kind of sad that this works. At least everyone who sees it should
know it's a bad idea.

 

[GaryM]

I'm kind of sad that this works. At least everyone who sees it
should know it's a bad idea.

I'm probably slow here, but why is it sad? Because the object get's
constructed despite thrown error in the constructor?

 

[Carl Howells]

I'm probably slow here, but why is it sad? Because the object get's
constructed despite thrown error in the constructor?

It just feels very wrong to have the constructor throw an exception, yet
still have the created instance be reachable. I realize there's nothing
in the language spec which says it can't or shouldn't happen that way...

But it seems like a very BAD design, no matter what.

 

[GaryM]

It just feels very wrong to have the constructor throw an
exception, yet still have the created instance be reachable. I
realize there's nothing in the language spec which says it can't
or shouldn't happen that way...

But it seems like a very BAD design, no matter what.

IIRC, an exception in the constructor causes the object to be
immediately eligble for gc. However this does not apply if a
reference is held to the instance. This is an excellent thread I
recalled reading some time ago:

http://groups.google.com/groups?hl=...06020851.5b9c72d1%40posting.google.com&rnum=9

 

[Tony Morris]

It just feels very wrong to have the constructor throw an exception, yet

still have the created instance be reachable. I realize there's nothing
in the language spec which says it can't or shouldn't happen that way...

But it seems like a very BAD design, no matter what.

Your reasoning is flawed.

Object o;
try
{
// This could throw an exception, in which case, o isn't assigned.
// So what?
// A red herring, until proven otherwise.
o = new SomeClass();
}
catch(SomeCheckedException e)
{

}


--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Mike Schilling]

IIRC, an exception in the constructor causes the object to be
immediately eligble for gc.

Only because there will, in general, be no references to it.

However this does not apply if a
reference is held to the instance.

Precisely.

Here's an example even uglier than Carl's; the partially constructed object
is resurrected by its finalizer:

public class Ugly {
public static Ugly ugly;

public void create() {
new Ugly();
}

Ugly() {
throw new RuntimeException();
}

protected void finalize() {
ugly = this;
}
}

 

[Derek Chen-Becker]

Only because there will, in general, be no references to it.



Precisely.

Here's an example even uglier than Carl's; the partially constructed object
is resurrected by its finalizer:

public class Ugly {
public static Ugly ugly;

public void create() {
new Ugly();
}

Ugly() {
throw new RuntimeException();
}

protected void finalize() {
ugly = this;
}
}

Whoa, that's beautiful. I'd like to think that all of these constructs
are merely academic; that no sane programmer would ever come up with
this. Sadly, I have a nagging feeling that somewhere, somehow, someone
has come up with something similar and said "Hey, what a great idea!"
This particular example serves as a good case point for the advice:
Avoid finalizers (Bloch, Effective Java p. 20)

Derek