unchecked exceptions are like runtime type checking?

I've been having a running discussion with a coworker of mine. He's a big fan of Ruby, while I find its runtime type checking worrisome. His recent response to my concerns about runtime type checking is that in the Java arena people are pushing using unchecked (runtime) exceptions, and that unchecked exceptions are just as unsafe as runtime type checking. In a way I can see his argument, because in Ruby if you misspell a method name it will throw a method not found error, so you could look at Ruby's runtime type checking as simply a source of unchecked exceptions.

But I have this sense that it's not quite that simple and can't put my finger on why.

unbound -> late binding

I'm just guessing I'm on topic, based on seeing hot code replacing right before a question about doesNotUnderstand. In the context of runtime exceptions, you can try to fix problems in-place rather than doing a non-local exit. When no method is found, you can represent this explicitly by dispatching doesNotUnderstand, which might fix the fault.

Paul Snively: I'm having difficulty seeing "doesNotUnderstand" as a benefit. Could you perhaps explain what you mean here?

For example, I used doesNotUnderstand at Taligent for lazy library loading. When I had a class Foo implemented in library Bar, I needed only define a stub for Foo with not much more than doesNotUnderstand defined, which loaded library Bar and then re-dispatched with the original message.

(No, we didn't use Smalltalk at Taligent. One of my several personal projects overlapping with uses at work included a total rewrite of XLisp that added things I wanted from Scheme and from Smalltalk, so it had a bluebook style object system. Because dynamic languages were essentially forbidden at Taligent by the static religion, I used this to write ad hoc scripts for driving things in unit tests.)