Perhaps this discussion should be moved to a Java group. As far as I
can tell, it has nothing to do with mechanical sympathy.
On 08/15/2016 05:00 PM, Vitaly Davidovich wrote:
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
<mailto: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
<mailto:mechanical-sympathy+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout
<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
<mailto: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.
