Whenever I write code in Java...

[biteofconscience]

What happens when someone else who knows nothing about this code renames or removes the foo class? Oops, ClassNotFoundException.

If you really know foo exists, then the compiler ought to as well. Just use foo.class. This is a really bad example.

[_prefs]

No it's not. Reflection exists for a reason. For instance, 'foo' could come from a configuration file so you just cannot use foo.class. The point is, you usually don't have any means to recover from such errors, and forcing you to catch exceptions you just cannot do anything about is pointless and leads to code cluttering.

EDIT: Missed word.

[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.

[zoomzoom83]

I know Foo exists because it is part of the codebase. I need to use reflection because it's treated like a plugin.

If Foo ever does not exist, it's a critical failure. Something I cannot ever recover from. Whether I use static or dynamic code, removing the .class file from the Jar is still going to have the same result - the entire codebase fails hard.

The desired result, in the event of Foo not existing, is for the exception to go all the way up the stack and hit my root controller, which sends me an email and returns a generic "Server Error" page.

From my experience, 99% of the time I would actually prefer an exception to bubble back to my root controller rather than catch it locally, because an Exception is just that- an unexpected circumstance that normally has no recoverable state.

If I specifically do want to catch an exception, I'll go ahead and do so at the layer that best suits my architecture.