Does overuse of Checked exceptions really annoy you?

Question

Im a big advocate for using Runtime exceptions for programming errors (e.g, violations of pre-conditions etc).
I find it really annoying when checked exceptions are overused to 'enforce you to do something about your programming error'.
Ive been on projects where an underyling 'untrust' of some developers ability to read an API to obtain pre conditions has led to a prolification of checked exceptions in central APIs.
e.g, Im a strong beliver (as I expect most are), that this is correct:
if(myContainer.contains(someKey)) {
  // Throws 'NoSuchObject' which is a RuntimeException if not contained
  myObject = myContainer.getSomeObject();
}and that this is not:
  if(myContainer.contains(someKey)) {
    try {
      myObject = myContainer.getSomeObject();
    catch(NoSuchObjectException) {
      // Typical 'This Cant Happen' comment (uurrgghhh...)
  }This basically comes from tech-leads having a lack of trust in the ability of some developers to unit test their classes properly.
However, it leads to absolutely horrendous code!
Has any one encountered this anti-pattern on their projects?
And what Im alluding to.... Has anyone managed to come up with a completely convincing argument to remove it?

Answer 1

There's a place for checked exceptions, but not usually for programming errors. That's why NullPointerException is unchecked. But checked exceptions for catching things beyond the programmer's control can also run amuck. Here's an example of code I have in production:try {
  dq.write(translator.toBytes(s));
} catch(IllegalObjectTypeException _ex) {
  throw new ScannerException(_ex.getMessage());
} catch(InterruptedException _ex) {
  throw new ScannerException(_ex.getMessage());
} catch(IOException _ex) {
  throw new ScannerException(_ex.getMessage());
} catch(AS400SecurityException _ex) {
  throw new ScannerException(_ex.getMessage());
} catch(ErrorCompletingRequestException _ex) {
  throw new ScannerException(_ex.getMessage());
} catch(ObjectDoesNotExistException _ex) {
  throw new ScannerException(_ex.getMessage());
}The "dq" variable refers to a DataQueue object from IBM's JTOpen product for AS/400 connectivity. Okay, there's a lot of things that could go wrong in this case, but in practice everybody is just going to log the fact that something went wrong and shut down. Six different exceptions is just overkill -- I suppose I could just catch Exception but that isn't a good practice either.