DWR - Easy AJAX for JAVA

Pretty good introduction to Direct Web Remoting in February's DDJ.

Please log

I respectfully take exception to Benjamin Booth's Pragmatic Exceptions tip #6 as published in the February 2006 DDJ (page 24).

He there recommends that you not both log and throw an exception.

Bad. This will most likely result in seeeing the same exception message at very different points in your program's execution. The problem is, it's the same error!

No, it's not. It's the same exception. It's not necessarily the same error. At least, not in the ways that matter. Context matters.

Ideally, your code will log its progress and the problems it encounters. Ideally, it will do so providing locally appropriate context. "Here's the exception I encountered, here's what I was doing when I encountered it, and here's what it means to me."

Remember your purpose in programming your module and in adding logging statements in the first place. The logging statements are to make the code more literate and to support current and future development and debugging. Logging the exceptions encountered, especially with appropriate context, is in keeping with this purpose.

When I encounter your code's exception, will it log the error before allowing it to escape the module, or will it just throw it up hoping that the outside module will log it appropriately?

I'm much happier to see an error logged twice with appropriate context, than not logged at all.

Benjamin wrote:

"[both logging and throwing an exception] sends an ambivalent message to callers of your function. The pitcher is saying to the catcher, "I'll log this now but, well, I'm not sure, it could be fatal, perhaps you should deal with it too?" This isn't only weak minded, it's also lazy and pathetic."

Wow. I think that's too harsh. I also think it's just wrong.

What my code does with an exception before it throws it is none of your code, the calling code's, business. The method signature and logging behavior are only loosely related at best. Certainly someone should be sure to log the exception, and I might provide a guarantee about whether my method will log it before it throws it to ease your handling burden. But exceptions are about much more than logging the exceptional condition. When my method throws an exception, it does so to communicate a result, and you, the caller, are advised of this result by receiving the exception, and have an opportunity to truly handle it, rather than just log it.

I wrote a letter to DDJ in response to this tip.

Senior Analyst/Programmer Java opportunity

Indiana University is seeking a highly motivated Senior Analyst/Programmer to work on enhancements supporting their Human Resources Management and Timekeeping systems deployed in a J2EE AIX Oracle infrastructure environment.

Engineering Software

Your component will fail. The input will be bad. You're going to screw up and get a null pointer exception. Even if you're perfect, some imperfect person will touch your code long after you've moved on to other projects.

So the question is this: is your system engineered to fail gracefully, or will it do the domain-equivalent of cutting the user's finger off?

Implementing Copy Constructors using Spring BeanUtils.copyProperties()

I got interested in automating copy constructors today and realized what perhaps is obvious and certainly others have already realized: that Spring's BeanUtils copyProperties() method can be an effective tool for quickly implementing copy constructors with support for copying appropriately from within a class hierarchy.

On What Computer Science Is

I found interesting Joel's post on what Computer Science is, and what it is not, and perhaps on why my career is so different from what I studied in college.
A particular zinger that hit close to home:

But JavaSchools also fail to train the brains of kids to be adept, agile, and flexible enough to do good software design (and I don't mean OO "design", where you spend countless hours rewriting your code to rejiggle your object hierarchy, or you fret about faux "problems" like has-a vs. is-a).

And, on why becoming a Java programmer is an insufficient aspiration:

"I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone."

Becoming an effective Java programmer is the employable side effect, not the goal, of a computer science education.
Makes me kind of want to work some CS 223 and CS 323 problems just to keep my brain from atrophying.