It's sure been a long time since I wrote anything for this blog. I've been in one of my geek funks. Every now and again I get into a mode of what I suppose is disillusionment. I get sort of sick of seeing the same discussions flowing across the net and despair at the lack of what I perceive fundamental progress being made. For a time building things loses it's attraction.
The first time this happened, perhaps 15 or so years ago, I started looking into other careers. I guess not surprisingly there wasn't a whole lot that appealed to me. As it happened I found the book Hackers by Steven Levy. I have no idea why but the book was entirely inspiring. I noticed that I was interested in coding again, in building things again. I found myself again seeking elegance in my creations instead of typing in whatever crap might work. It was a relief to realize that I wasn't going to be a sales guy, or a marketing droid or some other equally near death creature.
Anyway, I've been in a geek funk recently. I'm coming out of it now. I pulled out my copy of Hackers with it's browned, dog eared pages, each one nearly sucked dry of inspiration. But it helped. Free flow of information, as a principle, never seems to grow old. When I was putting Hackers back up on the shelf my eyes brushed across Alexanders The Timeless Way of Building. I simply love this book. It's eloquent valuation of the beauty of creations (not creation) nearly brings tears to my eyes.
I bought a Powerbook. One of the new ones. I'm sorry but I just love OSX. I've used I don't know how many machines and OS's, C-64, Apple II, SunOS, VMS, MVS, Xenix, SunOS, Solaris, Linux, DOS, Win32 in many stripes and, without question, my Mac is the finest box I've used in 20 years. It is absolutely beautiful. My previous laptop, a Thinkpad, ran linux. Linux is nice, largely because it's Unix and if you write code then Unix has the tools you want to wield as you chip away at whatever your sculpture of the moment happens to be. But it's really a pain in the ass. I didn't get sound working for a while, dealing with wireless was sort of a bitch, and wrestling with package dependencies...I'm looking for some scotch as I type this.
Finally, and just in the last 2 weeks, I broke out the big guns. I wasn't actually conscious doing this to de-funk, it just sort of happened. I started writing some code that uses Jini. It's a stupid little thing that processes batch requests for generating sets of data. I was on the couch one night, kids in bed, with my ever so nice Powerbook, using the most excellent IntelliJ, more or less absently minded typing. I wasn't quite sure where I was going, but I was moving. So out of the blue, like a fever broke, I got excited.
See, I love Jini. It's just so, what, eloquent? There's not a lot to it really. I mean the number of interfaces in the Jini spec is pretty small. But the ideas these relatively few interfaces embody are just so, pretty. I really don't have the words. Of course Jini also happens to talk right to my soft spot. I'm incredibly enthralled with building systems that run by themselves, that are tolerant of inevitable human error. Jini seems custom built for that. As I was typing along Jini was forcing me to catch exceptions it throws. For a few minutes I was frustrated. Code I write for a living smothers exceptions, or they're undeclared. That's sort of nice in some ways and, given the philosophy of that system, it makes sense (not really, but I don't get to make those decisions, so I tell my front brain things are fine so I don't go crazy). But I realized that the exceptions I was catching in this Jini code were actually useful. They were suggestions to me that said "this might happen, and you should probably deal with it if you don't want things to go boom". Nice.
I'm firing up IntelliJ now. I'm gonna write some code. I hope it turns out as nice on the screen as I see it in my mind. If not, well, I guess I'll try again.
If you can make time to learn about Jini, and to then use Jini, you can eventually see the importance of the simplifications the interfaces provide and the power that those simplifications create for you in solving your distributed computing problems.
Many people are really frustrated by all the 'Extra Work' involved in RemoteException handling. Many are really well practiced at this Exception burying that you describe. I have, over the years, argued that RemoteException should have been unchecked. I did not mean that you shouldn't have to check them. I have a habit of putting
try {
...
} catch( Throwable ) {
}
in important threads (in multiple places) already, whether or not that are making remote calls. I have logging facilities that allow me to see when things fail, and I have retry strategies in places that I know might be intermittent problems.
What I was arguing is that if RemoteException had been unchecked, then I could have done less work to add RemoteException handling. I understand why it was a checked exception, it just would have been easier for me, if it wasn't. So, we all get to deal with this explicitly.
From my early days of programming, I learned about handling every single error explicitly. I was harranged by my friends and collegues everywhere to not cut corners. So, it is embedded deep in my psychy. I guess others have different experiences or different motivations for their styles and habits...
Here's some common templates that I use...
In Swing/AWT for GUI threads
new ComponentUpdateThread( comp ) {
public Object construct() {
try {
...data = remote call to get data...
...sort list or otherwise...
return data;
} catch( Exception ex ) { // Catch everything
reportException(ex);
}
returnnull;
}
publicvoid finished() {
try {
...data = (cast)getValue();
} finally {
super.finished();
}
}
}.start();
In servers or forever threads, I use this pattern to allow me to call the processing loop for one iteration during testing or for other reasons. As an asside, I always declare all exceptions on the throws clause of doProcessing to properly document everything that is comming back. That way I can redesign what run() does or another path of execution at anytime and deal with a particular exception explicitly.