The debate on handling exceptions and dealing with potential errors continues. You may remember this from James Gosling's July blog entry Flying at Mach 1 "If you want to build something really robust, you need to pay attention to things that can go wrong and most folks don't in the C world because it's just to damn hard."
Bill Venners continues his series of interviews with James and the current installment is on Failure and Exceptions . Gosling stresses spending time considering the things that can screw up. The small things - like opening a data file to read.
This struck a nerve. I'm embarrassed to say that this is a mistake similar to one that I recently made. As Gosling points out, Java doesn't let you make such mistakes without consciously deciding not to deal with some required exception. I was sending and receiving information across a wire. I knew the size of the message but was ignoring the return of the open message. Nothing went wrong (of course) while I was testing the code, but fortunately a second pair of eyes spotted the omission and the resulting code was more robust. As Gosling points out,
A programming language can't solve all the problems. A language can't guarantee that no matter how screwed up the environment gets the program will survive. But anything the language can do to increase the probability that programs will be reasonably graceful under fire is a good thing. For example, just making people at least willfully ignore return codes helps. In Java you can ignore exceptions, but you have to willfully do it. You can't accidentally say, "I don't care." You have to explicitly say, "I don't care."
Gosling recommends frequent catches to deal with problems near where they happen. "Having one big catch clause on the outside really only works if your exception handling philosophy is simply to die." He also explains that just catching an exception isn't enough - you need to carefully consider what to do with it. Venners asks Gosling about the complaint that "in practice Java's checked exceptions encourage a lot of empty catch clauses." Gosling answers,
Anytime somebody has an empty catch clause they should have a creepy feeling. There are definitely times when it is actually the correct thing to do, but at least you have to think about it. In Java you can't escape the creepy feeling.
It really is a culture thing. When you go through college and you're doing assignments, they just ask you to code up the one true path. I certainly never experienced a college course where error handling was at all discussed. You come out of college and the only stuff you've had to deal with is the one true path.
In his Weblog entry A funny thing about XP , Erb Cooper chuckles about being able to find a mistake in code written by a pair that depended on code that he had written alone. He concludes that "perhaps it also shows that good old code reviews may be at least as good as pair programming. This assumes code reviews are carried through. I have been at several jobs where we started out with the intention of having code reviews, had maybe one or two, and then it fell by the wayside."
I've always felt that pair programming was orthogonal to the other XP practices - and I've never felt it was the most important one. Because it is such a visible practice, developers often equate pair programming with XP. I would argue that the "life changing" practice is test driven development.
Our other featured weblog entry today is John Bobowicz's take on Web Services:The glue or just more rock and scissors? JBob argues that Web Services doesn't remove "the burden of picking a platform" and suggests that you will still need to make a choice between .Net and J2EE. As usual, the discussion continues in the talkback where zander responds that "A datacenter does not support protocols; it supports platforms. The developments provide choice; choice to have 2 (or more) platforms for a certain time. Time enough to migrate everything".
In Also in Java Today , Brian Connolly writes about tracking and recording response times in web applications. In his JavaWorld article Client quality reporting for J2EE Web services he shows how to use a SOAP attachment to upload response time reports to the server so that you can accurately evaluate your customer's experience. For a little fun, we also link to the Metaweb wiki which built around "the ideas and historical period explored in Neal Stephenson's novel Quicksilver." Java related - not really. It's just a nice diversion for Java developers and further justification for your employer to take away your internet access at work.
Today in Projects and Communities, the community manager for the Java User Groups community is exploring how the java.net tools can best serve JUGs. Take a look at what his SouJava JUG has done with their project space. Interested in participating in the Java Web Services and XML community. You'll be interested in this article on What's new in the Java Web Services Developer Pack . The article includes links to the various technologies and a summary of what is included in the latest release.
In today's java.net News Headlines :
- OASIS Ratifies SAML 1.1
- Five More OEMs for Java
- AspectJ 1.1.1 and Accompanying Tools Released
- RaveGeo Initial Release
- JSch 0.1.8 Released
Registered users can submit news items for the java.net News Page using our news submission form. All submissions go through an editorial review by news director Steve Mallet before being posted to the site. You can also subscribe to the java.net News RSS feed.
Current and upcoming Java Events:
- 9/24 A Peak at TIGER New York, Java SIG meeting
- 9/26-9/28 Salt Lake Java Software Symposium
- 10/13 - 10/15 ITU Telecom World 2003
This blog is delivered weekdays as the Java Today RSS feed. Once this page is no longer featured as the front page of
href="http://today.java.net"> Java Today it will be archived at
http://today.java.net/today/archive/index_09242003.html. You can
access other past issues in the java.net Archive.