Why is it egregious? It's detailed in the types of exceptions it throws,
yes, but that's good assuming you want to handle some of those types (and
there are cases where those exceptions can be handled properly). Even
before ReflectiveOperationException, you could use multi-catch since Java 7
to get a bit more ergonomics. IMHO, it's better than "throws IOException"
-- that tells me nothing, really. Is it the disk/media is full? Is it
because file/dir not found? Is it because I don't have permissions? The
javadoc for it says "Signals that than I/O exception of *some sort* has
occurred...", emphasis mine. Granted, there are subtypes and some methods
throw checked subtypes. But just "some sort" is nearly worthless since
some exceptions may be handled properly, whereas others denote a case where
you cannot continue.
I do agree that checked exceptions are tricky to use right, mostly because
they require the same rigor and thinking that defining the rest of the API
requires (e.g. what return types are returned). Once you define an API to
return Foo, you're on the hook for returning Foo (or subtype) or else you
break code. Exceptions, checked or not, are just another return value from
a method. One can return Object, and then not worry about breaking
compilation either, but most code doesn't do that. So, it helps to think
of checked exceptions as a typed return value from a method, and give it
the same type of diligence as the rest of an API.
On Mon, Aug 15, 2016 at 9:47 AM, Eric DeFazio <edefa...@gmail.com> wrote:
> IMHO the most egregious use of ChekedExceptions is in Javas Reflection
> API, and I cry when I think how beautiful it could have been verses how
> cumbersome reflection can be (My SmallTalk friends laugh about it)
>
> (To construct an instance of an object and then call a method on it)
>
> try
> {
> Class clazz = Class.forName( className );
> Class[] ctorParams = {String.class, String.class, Integer.TYPE};
> Constructor ctor = clazz.getConstructor(ctorParams);
> Object person = ctor.newInstance("lastName", "firstName", 20 );
> Method toStringMethod = clazz.getDeclaredMethod(methodName);
> System.out.println( toStringMethod.invoke(person) );
> }
> catch( ClassNotFoundException cnfEx )
> {
> }
> catch( NoSuchMethodException nsmEx )
> {
>
> }
> catch( IllegalAccessException illAccEx )
> {
>
> }
> catch( InvocationTargetException invokeTargetEx )
> {
>
> }
> catch( InstantiationException ctorEx )
> {
>
> }
> Granted, this changed in Java 7 (all those exceptions are subclasses of
> ReflectiveOperationException)
> try
> {
> Class clazz = Class.forName( className );
> Class[] ctorParams = {String.class, String.class, Integer.TYPE};
> Constructor ctor = clazz.getConstructor(ctorParams);
> Object person = ctor.newInstance("lastName", "firstName", 20 );
> Method toStringMethod = clazz.getDeclaredMethod(methodName);
> System.out.println( toStringMethod.invoke(person) );
> }
> catch( ReflectiveOperationException re )
> {
> }
> But still, I think given how widely used a language feature like
> Reflection is, and how many Libraries, Tools, and Frameworks use
> Reflection... this was just a terrible API design (along with JDBC)
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
