Benjamine Carlyle and I have been discussing exceptions. Put simply, he hates them, I love them. I think I know why now.

Adrian Sutton argues that exceptions are not in fact harmful but helpful. I don’t know about you, but I’m a stubborn bastard who needs to be right all the time. I’ve picked a fight, and I plan to win it ;) I’m also a stubborn bastard (just ask Byron about ampersands), so let the death match begin! Actually, as I mentioned in this case I think we’re arguing different things so we might be able to resolve this amicably. Benjamin’s biggest problem with exceptions is that code in between the throwing of the exception and the handling of the exception “gets hurt”. The answer here is called abstraction. Abstraction in this context has a very simple tenant: when I call a method, it does stuff and I don’t care how it does it. In other words, if I call the method doStuff(), I don’t care if an exception is thrown in a deeply nested function call or directly by doStuff, to me doStuff simply through an exception. This is then true for doStuff, it only cares about each method it calls and not any methods under that and so on. So for any given piece of code we only think about one level. Methods and classes provide abstraction. Now that we’ve abstracted things, there simply is no code left in the middle to get hurt. Each method should handle whatever exceptions it may cause in whatever way it needs to. It’s the whatever way it needs to that differentiates Benjamin’s viewpoint and mine. Benjamin has been talking about exceptions in C++ whereas I have been talking about exceptions in Java. In C++ when an exception is thrown you have to carefully sort out what memory you had already allocated and not freed then make sure you free it etc etc etc. In other words, an unexpected failure is catastrophic and pretty much unrecoverable. In Java however, it’s no big deal at all. Objects will happily be garbage collected when no longer required, it’s simple to tell if objects have been created and it’s also really simple to clean up any allocated resources. So in Java if we were working with a database, we’d do something like:

Benjamin claims that exceptions are evil, he couldn’t be more wrong. Exceptions are in fact one of the best ideas that has been added to languages, particularly checked exceptions which force people to deal with error situations. Benjamin’s first problem with exceptions is that they’re impossible to test. This assertion is flat out wrong. Exceptions simply make you aware of a case that you’re not testing. For instance, say we have a function that writes to a file, as part of our testing we should test that it behaves correctly (ie: produces the expected behavior) even in situations when the file can’t be written either because of a lack of permissions, a full disk, missing directory, network error or hardware failure. It doesn’t have to work in those situations, but it must behave predictably because one or more of those situations will occur when the program is in production at some point or another. Without exceptions, the code might look something like (using some convenient but totally fictional libraries):

(I’m upping the anti)

The next person that whinges about restriction of smoking to private homes will receive a free gift. Yes ladies and gentlemen I shall stand next to them, and share with them the gaseous byproduct of my digestive process. It�s my RIGHT isn�t it? Isn�t it? — David Jericho No it is not. Quite the opposite in fact. As part of your right to life, you have the responsibility to not interfere with the right to life of others. Since smoking reduces the expected life span of the people around you via passive smoking, you are interfering with their right to l’#8217;m sure you could also word that around having the right to not have people reduce your health’#8217;m not sure how to word it clearly and the right to life is a far better established right. As for the threat to share the “gaseous byproduct of my digestive process”, were it enacted, I would be forced to remove the fire hazard with extreme prejudice (and the closest bucket of water). UPDATE: er, clea’#8217;m an idio’#8217;m agree with David entirely. I guess I got confused with the anti-antiness of it all.

If you ever try to download, burn and install the Ubunto warty ISO image on OS X you’ll find that Disk Utility crashes and hdiutil crashes. To get it to burn you need to install cdrecord using fink (fink install cdrecord) and then use the information on this page to work out how to burn it. On my PowerBook G4 with a DVD-R/CD-RW drive I used the command: sudo cdrecord -v speed=24 dev=IODVDServices warty-rc-install-powerpc.iso and it’s working fine. We’ll see how it goes from here on in.

Iain points to this gem of an article. Some choice quotes:

Dr Greening and colleagues asked 42 men to ejaculate every day for seven days Excuse me Sir. Yes, sorry to interrupt – would you mind doing me a favor? Yes, I just need you to jerk off every day for a week. … Say, how’d I wind up in hospital again?

I think it’s exciting Don’t we all Dr Greening. Don’t we all.

I’ve had my old powerbook lying around for a fair while now not doing anything so I thought it was time to put Linux back on my desktop. I’ve pulled the laptop back off the shelf, booted it and found Debian is already installed and running okay. So I officially have Linux running on the desktop! Now what?

Martin Pool gives an informative pros and cons list of Ubuntu Linux versus a number of other OSes. I’d like to jump off on a tangent. Martin gave a plus ot Ubuntu for:

• Less Macintosh historical baggage. Mac apps can be in the wierd state of running but having no windows open: GNOME designers just know this is silly. OS X suffers some friction between the Mac and Unix parts, in e.g. case sensitivity or resource forks. While there is definitely some historical baggage in Mac OS X (not much mind you – Apple were pretty ruthless with cutting things out), the ability for an application to be running without any windows open is actually a design feature and not historical baggage. When described as “the wierd state of running but having no windows open” it sounds downright stupid, but if you describe it as “the ability for the menubar to not disappear suddenly when closing a window” it makes a lot more sense. The Macintosh menubar is placed at the top of the screen because it’s significantly faster to access the menus when it’s placed there (plenty of research backs this up – essentially the sides of the screen have infinite depth so they’re easy to hit). Since the menus are at the top of the screen and not in the window, it makes no sense for the menubar to change when you close a window. Thus, when closing a window in an application the application continues running allowing you to open a new document, adjust preferences etc etc. That’s not the only reason though. Think of someone using pen and paper who has two tasks to complete. They start the first task by getting out a clean sheet of paper and writing on it until they are finished. Then they file that piece of paper away. Finally they start the second task by getting out another clean sheet of paper and starting writing again. In other words, the life cycle is:

1. Create a new document.
2. Work on document.
3. Save and close document (filing both saves the paper and removes it from the workbench)
4. Create a new document. If you were using Gnome, Windows or pretty much any OS other than Mac OS, step 3 would suddenly cause your pen to jump back into the drawer. You’d actually have to rethink the order you do things in to open a new document before you close the previous one. Now you might argue that people typically work on more than one thing at a time and they are likely to have both documents open anyway. They might indeed but in that case there is another subtle benefit. When they decide they’ve had enough of work and want to put it all away and play a game, they simply hit command-Q and all of the documents in that application close. It’s like having a bulldozer that can file things neatly. The disadvantage to the Mac OS way of doing things was that on OS 9, you didn’t realize the application was still running and either ran out of RAM or got really confused when you next double clicked on the application and nothing happened (in fact the menubar changed but noone seems to notice that). OS X (and the magic of modern computing) solves both these problems. Firstly, you won’t run out of RAM anymore because OS X has virtual memory and the ability to move things around in RAM (OS 9 loaded things in order and fragmented memory effectively couldn’t be reclaimed – plus the virtual memory was really bad). You could leave every application on your system open in OS X and it just wouldn’t matter because the unused applications would be paged out to virtual memory. Note that because they are unused they wouldn’t constantly have to be paged back in either so no hard drive thrashing. The second problem is solved in two ways. Firstly there is a reasonably obvious indicator that an application is open (the icon appears in the dock if it wasn’t already there and a black triangle appears under the icon). This helps a little, but not a lot. The biggest improvement is the Aqua Human Interface Guidelines change which now requires that when the user clicks on an application in the dock or double clicks it in the Finder (the same actions used for opening it) the application will bring it’s existing windows to the front if it has any, or create a new window if not. If you combine the effects of these two changes, the result is that the “weird state” of an application being open but with no windows effectively ceases to exist. The user can be completely unaware that the application is running and continue to go about their work without ever noticing. When they try to open the application again it behaves exactly as it would have when first opened and displays a new window. There is no noticeable impact on resources because the RAM can be swapped out to disk and made available to other applications and modern hard drives have plenty of space to cater for this. The user is now able to operate in their logical order without menubars unexpectedly changing on them. So as it turns out it’s the GNOME developers who got the UI design wrong predominately by putting the menubar in the window instead of at the top of the screen. Once they’d made a mess of that behavior, it wasn’t really an option to avoid the disappearing menubar problem because the menu is so inextricably linked to the window.

My Queen CDs are here! Yay! I ordered “Queen – Greatest Hits I, II & III” a week or so ago after getting hooked on both We Will Rock You and A Night At The Hip Hopera and it’s finally arrived. I’m in the process of dumping into iTunes now (Apple lossless encoding so even the purists should be happy) and will then commence burning a copy of the CDs to listen to in the car (CDs don’t tend to like the extremely high temperatures cars get to around here). I don’t particularly care if that illegal in Australia – I want my Queen in an accessible format and I don’t want the CDs to get wrecked. Besides, since I bought it from the US I get the same rights as if I were in the US right? I like that logic anyway. Besides, I just deserve it, I’ve earnt it – it’s my precious.

A little while back I said duplicate code was the biggest codesmell I knew of. I was wrong. There is a level of smelly code that goes well beyond duplicated code, in fact it goes well beyond anything a professional programmer would ever do. That is the smell of code that doesn’t have JavaDoc comments. From time to time every programmer will get lazy and not bother to add a comment for something but every so often you come across a code base that seems to have a systematic policy of removing any JavaDoc comments that might prove useful. Sadly, I was reminded of this when attempting to use BCEL. Vast swaths of that project are completely devoid of JavaDoc comments. Maybe the functionality of those methods are completely obvious to anyone who’s ever touched the codebase, but I’m trying to work out how to use the library so I need to at the very least be told “this method is not for you – go away”. In the end I gave up and used ASM which is still fairly light on JavaDocs at times and quite often the JavaDocs that are there are too abrupt to be particularly useful but at least there’s something. All the same, the process of using ASM is essential a case of trial and error unfortunately. So if you ever teach anyone Java, beat into them how useful, powerful and important JavaDoc comments are. It doesn’t matter how neatly laid out your code is or how obvious the functionality may be – most people who go to reuse the code are going to look only at the JavaDocs either through the generated HTML or through their IDE. Make sure the information there is useful.

It appears the java.net crowd picked up on my labeling some of them wingers – the response has been much more polite than I would have expected (or deserved really). The most well reasoned response so far is from Chris Adamson who points out the history of Java releases lagging behind on Mac as a reason for people to be worried. Before I go into Chris’s comments, let me point out that there are two main groups of people:

Oliver Hutchinson commented on my last code duplication entry:

Another way that duplication sneaks in is when people reimplementing something for which there is already a perfectly good library. For instance, your example of arranging dialog buttons in the appropriate order for the platform is taken care of very nicely by the JGoodies forms library. Actually Oliver, this is the perfect example of when you should duplicate code. There are a few reasons for this, the most obvious one being that JGoodies depends on Java 1.4 and our software currently only requires Java 1.3. Dropping support for Java 1.3 (and thus IE on Mac) isn’t really worth it to save writing 4 lines of code. Secondly (and far more importantly), the JGoodies forms library provides an entire library for laying out forms. We don’t want an entire library for forms layout – we already have that problem solved using the standard classes in the JRE. The JGoodies jar file would add an extra 80k to our applet which while not awful, would be 79k or more we didn’t need. Thirdly, adding an extra library increases the chances of a conflict occurring in our JavaBean version if one of our customers is using a different version of the JGoodies library. To avoid this we’d have to rename the package which results in duplicated code again except now the entire library has been duplicated. Finally, the JGoodies code is significantly more complex than it needs to be. It’s simply not a good implementation given the set of requirements we have. The JGoodies implementation uses a Factory class, a Builder class, an AbstractBuilder class and a custom layout manager as well as a host of other classes. Our implementation uses a JPanel and an if statement. Granted, the JGoodies implementation is capable of creating a wide range of different button dialogs that work in a much wider set of situations, however none of that provides any benefit to our project. Adding dependencies is a choice that has to be weighed up very carefully and should never be done just to avoid writing a few very simple lines of code. Furthermore, when replacing duplicated code with a common library, it is imperative that the requirements (as opposed to the implementation or results) of both pieces of code are the same. It is not enough that they be similar, they must be the same – they have to logically be the same function before they should be made actually the same function. On the other hand, if JGoodies had already been in use by our application, Oliver would have been completely correct that we should have used the existing function because it did meet all the requirements and despite the fact that it met a lot of requirements that weren’t needed because we would have to test the custom layout manager etc so the complexity wouldn’t matter so much.

Well David is right. Queen Fans do love A Night At The Hip Hopera. Definitely worth a listen and props to David for bringing it to my attention.