subbu.org

I just noticed that my previous post has generated some heat at TSS.

To settle the heat, I would like to make a few comments. It is probably more appropriate to post these at TSS itself, but I would like to take an exception and post my comments here.

Some of the commenters were quite upset about the third example. The case in point is that coding mistakes like this do happen, and when they happen, the API user is totally lost.

Some commenters did not see the connection between usability and exceptions. I should have been clearer on this. An API is a contract with its users. In a layered or componentized software, layers or components talk to each other via established interfaces. It is not sufficient to abstract the feature-set behind those interfaces. It is equally important to properly sheild or escalate error conditions with meaningful exception classes and messages. Things that happen way underneath the implementation make little or no sense to the API user. The more meaningful the exceptions are, the better the experience of the user. This is usability, and bad exception handling does compromise usability of APIs.

[Updated a couple of hours later] I also noticed is that the question of checked vs unchecked exceptions is very contentious. Some don’t like checked exceptions, and some don’t like unchecked exceptions. But I think Sun’s Java Tutorial answers this question very well. There are reasons for both checked and unchecked exceptions. I do not want to venture into that discussion, but I stand by my point that unchecked exceptions tend to deemphasize usability.