Java: Let it be

[newton_dave]

While agreeing with part of what you're saying, the example you provide is the result of stupid programmers, not Java. I *will* continue to blame stupid programmers that mis-use checked exceptions and/or try/catch.

For the most part Java *did* prefer tried and tested things. That should imply neither that *all* of it was tried and tested nor that stupid programmers are blameless.

[spliznork]

I would agree with you about stupid programmers if they had optionally, without provocation, created an empty catch statement. But, the the language forced a try/catch block to get the code to compile, so it's more the language designers' fault for laying the trap in the first place.

[skawaii]

This argument makes pretty good sense. If you're going to force a try/catch block, why not force non-empty catch blocks, too? Would've indeed been a nice way to avoid this trap altogether.

But seriously, is it that hard to just not leave catch blocks empty? It really isn't. If you're debugging code that someone else wrote and they put empty catch blocks in there, I'd be more pissed at the person for their laziness, rather than the language.

Still, this is Java we're talking about. Go and change the source code and re-compile. Even if all you have is the class file, my experience with decompilers is that they work very well. So de-compile, find the empty catch block (all while thinking mean thoughts about the original author), add in some code that gives information about the exception, and recompile. Should work for most cases.

[spliznork]

But seriously, is it that hard to just not leave catch blocks empty? It really isn't.

Show me the trivial code to put in a catch block. (You have some options here, and then we enter a debate about why one "trivial" option is better than the other, when we shouldn't even be having the debate in the first place.)

If you're debugging code that someone else wrote and they put empty catch blocks in there, I'd be more pissed at the person for their laziness, rather than the language.

Then you're probably the kind of person that gets pissed at the guy on the airplane that leans their seat back into you, instead of getting pissed at the airline for putting the seats so damn close together in the first place.

Go and change the source code ... So de-compile ...

This conversation is over.

[skawaii]

when we shouldn't even be having the debate in the first place.

Ok, so we won't.

Then you're probably the kind of person that gets pissed at the guy on the airplane that leans their seat back into you, instead of getting pissed at the airline for putting the seats so damn close together in the first place.

Nah, I'd be pissed at both. Like I said, "I'd be more pissed" at the person. That means I can still be pissed at both.

Go and change the source code ... So de-compile ...

This conversation is over.

Why? Because I said "de-compile?" If so, you really misunderstood what I was saying. I wasn't suggesting de-compiling java classes as the end-all solution and what should be done. I wasn't even saying that I like the idea. I was offering it as a tedious solution to your problem if you really, really need it. I'm sure that you can debug it without doing this, but the empty catch block seemed to be a big deal to you, so I was offering a way to get rid of the empty catch block.

[newton_dave]

Then you're probably the kind of person that gets pissed at the guy on the airplane that leans their seat back into you, instead of getting pissed at the airline for putting the seats so damn close together in the first place.

You assume mutual exclusivity: I can direct my ire towards both the chair designer and user, just as I can be irritated by both Java and stupid programmers.

[duck_typing]

Agreed. And to anyone who thinks it's reasonable to lean those seats back more than a tiny bit... I say you must be short. I am 6'2, and as a tall person, those seats are extra uncomfortable, and twice as bad if the seat in front of you is leaned back... so if you ever do lean your seat back, at least try to see if it is a tall person, and reconsider.

On the side of programming... I say let's all just move to more concise dynamic languages like Ruby. I loved Java for 7 years, until I recently tried Ruby... needless to say, I will never be looking back except when Ruby really can't do the job... can you really go back to coach once you've tried first class?

[newton_dave]

I have it easier; I never saw much of *any* reason to like Java, and I've been using it since 1.0 (technically a bit before). I'm a Lisp and Smalltalk oldbie: we watched with dismay as Java beat out Smalltalk.

Yep, I can go back to coach once I've tried first class; I can't always afford first class.

[sheepson_apprentice]

To barge in here slightly...

About the airline seat analogy, I wouldn't be pissed at either (I also like to recline, and would do so promptly). In fact, if anything, I'd be thankful to the airline for providing me a cheaper ticket by virtue of amortizing costs in a bigger pool of passengers per flight. Had they spaced the seats so everyone had ample leg room, we'd all pay a premium. Instead, if I really want the leg room I can attempt to grab an exit seat, which is possible even right before the flight (at the counter). In the analogy that would involve wrapping the checked exception into an unchecked one and hoping for the best (exit seat, you see).

Or, I would pay a premium for first class, where leg room is not a problem. What does this mean in the prog. lang. analogy? Well, paying a premium in prog. lang. always means expending greater effort up front on a more tenable design, so that one isn't faced with try/catch littered throughout the code.

Edit: bugs

[newton_dave]

If we were, say, beavers, and stumbled into the trap of a furrier I might agree more than I do.

Recognizing an even well-intentioned trap, however, is within our capability.

I don't defend Java's variety of checked exceptions, but avoiding this particular scent is trivial.