Nice article here.

Interestingly enough, when doing my getopts TDD experiment, I decided to make OptionException -- the superclass of all exceptions raised by the library -- a RuntimeException rather than a checked exception. The rationale? You're probably using the getopts functionality up in a main() or nearby routine, and probably have a top-level handler to trap unforeseen issues...so why pollute the library's method signatures with a checked exception that surely will either 1) be handled at that top level as big-E Exception, or 2) not be handled as such, and the exception's message/toString() will be useful enough for the user to figure out what happened?

Most developers, I think, would knee-jerk and make OptionException checked. I did, but then turned my thinking around. What do you think?