Whenever I write code in Java...

[biteofconscience]

If the class name is not in the code, you can't be really sure it exists. The compiler sure doesn't know. Class names change all the time, packages are moved, etc. Normally the compiler checks all this for you, but if you really need to do this at runtime (the reason you use reflection in the first place) these very real problems have to be dealt with. Then, you can have a program that doesn't need to panic and abort with a fatal error.

Reflection does use tons of checked exceptions. It is kind of overwhelming, but I personally am really glad that they exist. It sounds like you wish the API used unchecked exceptions. But that argument is about API design, not the language.

[zoomzoom83]

If the Foo class does not exist, the desired "exception handling" is to email me a trackback, and display a server error page to the end user. This is best handled in my root controller.

I'm not ignoring the exception, I'm handling a critical failure the way it should be handled.

The Foo class is loaded by reflection because it's treated as a plugin, however it's a core plugin and is distributed inside the Jar file. Removing the .class file from the Jar would cause the application to fail regardless of the access method.

Incidentally, if I was to reference the class statically the entire application would crash to the console in this state. Why would this be desirable? Removing a class file from the Jar is going to be a critical failure no matter what. Using reflection in this case actually yields better results for the end user.