dwc

Beautiful

Such a sight to behold:

Almost

I'm almost done with undergraduate studies! I have two final exams - one on Thursday and one on Friday - and that's it! I'm not excited about having a final exam at 7:30 am on the day of graduation (which also happens to be my birthday).

I'm not sure if I will be allowed to keep my Grove account after I graduate. Since I'll be an employee, I hope they will let me, but the GatorLink site says "some staff", so I'm not sure.

Gaim Review

Ars Technica has a good review of alternative AIM clients for Windows. It echoes some of my complaints about Trillian, and gives a good rundown on Gaim.

Two minor points: The reviewer praises Trillian for displaying conversation history, but apparently didn't notice that Gaim has the same functionality in a vendor plugin. He also calls it "GAIM", which doesn't exist according to the Gaim developers (copyright concerns).

Five Simple Rules For Error Handling

I was reading C, Objective-C, C++... D! Future Or failure? this morning, and was surprised to see a comment that completely missed the point of exceptions and their benefits over other forms of error handling. I replied, arguing in favor of exceptions. Some people agreed with me, while others completely missed the point. Again.

(The rest of this discussion is heavily based in Java since it is arguably my primary language, but it applies to any language with (checked) exceptions for error handling.)

My main argument is that exceptions, when used properly, provide a much cleaner and more expressive way to handle problems than other forms of error handling, such as function return values. Proper error handling with checked exceptions isn't really that difficult:

1. Avoid integer return values, magic numbers, etc. for error handling. The practice of return -1 or return 0 should not appear in languages with exceptions. Consistency is much more difficult to achieve, and there is no telling what a specific return value means.
2. Avoid wrapping exceptions with empty catch blocks. I've seen entirely too much code that looks like:

   try {
    // ...
}
catch (Exception e) {}

   This can lead to some very annoying bugs, as your code has a decent chance of breaking with no explanation. If you don't know what exceptions might be thrown by a call you make, defer your decision on how to handle it until you compile or use an editor that tells you what exceptions are thrown (IntelliJ IDEA comes to mind, though there are many others).
3. If you don't know how to handle an exception in the current scope, pass control to the caller. For example, a method that authenticates a user against a database should not take control of the main program flow when it can't connect to the database. Declare your method as throwing the (specific type of) exception (and document the reason), where it can be handled properly ("There was an error connecting to the server to check your username and password. Please try again later, and if the problem persists, please contact $ADMINISTRATOR.", followed by a System.exit(1)). This is perhaps the most important rule to follow when using exceptions.
4. Document the reasons why your method might throw an exception. This helps you and your fellow programmers when you are using the code six months from now. Javadoc is one tool to use for this purpose.
5. Be a good little programmer and close file handles and database connections in finally blocks, if appropriate. For example:

   Connection conn = null;
try {
    // Open connection, possibly get an exception
}
finally {
    if (conn != null) {
        try {
            conn.close();
        }
        catch (SQLException ex) {
        }
    }
}

   This is the only case I've come up with that breaks the first second rule. You're allowing the exception to propagate to the caller, while still releasing resources when appropriate. (If something goes wrong when you try to close the connection, you could log the exception.)

Obviously, these "rules" are just suggestions. They don't apply in every case, and there are times when you might need to adopt different practices.

One final point: When programming in Java, I sometimes feel exceptions are being forced down my throat, whether I like it or not. Some people feel that checked exceptions are a little too much. Since I haven't worked in a language with exceptions that are not checked, I'm curious as to how well this works out.

Update: Fixed a minor mistake in the fifth rule.

Wonderfalls

I just read through Orkut that FOX has canceled Wonderfalls (warning: Flash). The news is on Buffistas and Ain't It Cool News.

First FOX canceled Firefly, and now this? I can only hope that FOX will release the remaining episodes on DVD. Please?