Ricky Clarkson

It's easy to compare the bytecode, take a look at javap.

The performance implications are negligible, if existent at all.

Look at it from a readability point of view instead. In small methods, multiple returns are fine. In larger methods, they may sometimes be confusing. But then larger methods may be confusing regardless.

You could use composition instead of inheritance.

Jim, I would disagree. You should encourage good behaviour, but not prevent bad behaviour, because there are times when such restrictions cause ridiculous workarounds, such as restarting a virtual machine to get a fresh instance of a singleton, or using separate classloaders.

Good programmers don't need shackles.

I decided that, at least for now, Haskell isn't for me. I don't need shackles to write programs, even if I can invent my own shackles.

Mr. Anderson,

Use a memory profiler.

Agent Smith.

Casting doesn't actually create or change anything at runtime, it just performs a check. The compiler must know what methods your objects have at compile time. Trying to cast to some dynamically-known type won't help. Learn how Java does OOP.

Stan, instanceof also disagrees with you. Between instanceof, me and Barbara Liskov, you're on the ropes.

Tony, that's not great, because you shouldn't let an exception escape a finally block, to stomp all over the exception that's already been thrown. Catch it and log it.

try { resource=open(); try { use(resource); } finally { try { resource.close(); } catch (IOException e) { log(e); } } }

Practically, there's no reason not to use the 'null' version. Null isn't so much of a problem if it can't escape the current scope:

resource=null; try { resource=open(); use(resource); } finally { if (resource!=null) try { resource.close(); } catch (IOException exception) { log(exception); } }

Of course, you can wrap this up to make nesting it less ridiculously complex. The only bits that really vary are the way to open a resource and the way to use it.

public static <T extends Closeable> void withOpenResource( LazyWithException<T, IOException> open, SideEffectWithException<T, IOException> toRun, SideEffect<IOException> exceptionOnClose ) throws IOException { T resource=null; try { resource=open.invoke(); toRun.invoke(resource); } finally { try { resource.close(); } finally { if (resource!=null) try { resource.close(); } catch (IOException exception) { exceptionOnClose.invoke(exception); } } } }

Which would be used like so:

withOpenResource(new LazyWithException<Reader,IOException>() { public Reader invoke() throws IOException { return new FileReader("file.txt"); } },new SideEffectWithException<Reader,IOException>() { public void invoke(Reader reader) throws IOException { int ch=reader.read(); //etc. } },new SideEffect<IOException>() { public void invoke(IOException exception) { log(exception); } });

Of course, there's only actually three lines of code in all that that are actually useful, and it seems a shame to have to have a separate SideEffectWithException as well as SideEffect.

You might think the above is poor code. It isn't, it's just code that's fighting against the language somewhat. Here's the same code in what Java 7 will likely look like:
withOpenResource(Reader reader: {=> new FileReader("test.txt")}) { int ch=reader.read(); //etc. }
Now it doesn't look so bad, does it?

[ inserted line breaks in overlong line of code - Jim ]
[ May 20, 2007: Message edited by: Jim Yingst ]

What's wrong with this picture is that you've instantiated the class directly instead of using the static field. You're fired.

Humour aside, I don't think good programmers need shackles, just encouragement to do the right thing.

No, it doesn't. I just tried it, and you can infer it from the original question anyway.

Casting is for magicians, not programmers. Stop casting, and you'll stop getting exceptions from casts.

In my opinion, single inheritance is one too many. There are better forms of code reuse.

There is something inaccurate in your description.

Nowhere in your code would you just print the OutOfMemoryError on its own - you have "Exceptional "+e in your handler.

So, what's your actual code, and what's the actual output?

Are you sure you're catching Exception (if so, why anyway?), and not Throwable? If you're catching Throwables, don't.

public class MyAmazingSingleton { public static final MyAmazingSingleton instance=new MyAmazingSingleton(); }
[ May 17, 2007: Message edited by: Ricky Clarkson ]

An instance of a subtype is an instance of the supertype.

"Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T." - Liskov substitution principle.

I'll let q(x) be that objects x are of type T. Then q(y) means that objects y are also of type T.

Having one class abstract is just an implementation detail, it doesn't change the concept.