Help coderanch get a
new server
by contributing to the fundraiser

Ricky Clarkson

Ranch Hand
+ Follow
since Jul 27, 2006
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by 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.
17 years ago
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.
17 years ago
Mr. Anderson,

Use a memory profiler.

Agent Smith.
17 years ago
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.
17 years ago
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.

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:

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.

Which would be used like so:

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:

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 ]
17 years ago
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.
17 years ago
Casting is for magicians, not programmers. Stop casting, and you'll stop getting exceptions from casts.
17 years ago
In my opinion, single inheritance is one too many. There are better forms of code reuse.
17 years ago
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.
17 years ago

[ 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.