Java Reflection Exception Jungle

[Chris Smith]

Fair enough. I can create a new FileNotFoundExceptoin2 class
that contains the information relevent to the event, the missing
file name.

Yes, basically. The name 'FileNotFoundException2' is obviously a little
brain-dead. You'd want something domain-specific that describes the
exception from a calling context, such as FooFileNotFoundException.
You'd possibly also want to include more information about the details
of the foo-file element that referenced that file.

The exception is acting, then, not as message, but as a flag, for a
particular type of error,

Exceptions have two purposes. By their type, they identify kinds of
errors. By their instance state, they identify information about a
specific error. Undoubtedly, the first use is primary. However, the
second use is important, as well. Standard exceptions contain such
information as the stack trace, detail message, etc. When you define
custom exceptions, you can add more context-specific state.

I am responsible for creating a proper event object.

I wouldn't put it that way. Instead, I'd say you are responsible for
ensuring that exceptions thrown from your code are useful in the calling
context. For all of the standard API routines that throw
FileNotFoundException, the exception is sufficient in the calling
context to identify all information about the exception that occurred.
If you intend to use it in some more elaborate way, then you should use
chaining and possibly your own exceptions to be sure that it remains
that way.

In that case, it is not an abstraction, it is merely a language
construct. A block is a block, true, can't argue with that.

I don't understand what you're saying here.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[John C. Bollinger]

(e-mail address removed) wrote:

[...]

Well, then, reflection for bootstrapping is a common
application.

Inasmuch as I think I understand what you mean, I lump this in with
configuration, which I think we have settled of to our mutual
satisfaction. It is a situation where reflective instantiation may
often be useful, but where reflective method invocation is rarely, if
ever, the only viable option.

Once things are rolling, I'm against the use of instanceof.

I am of the same mind, but I don't see how that's germane.

I prefer to program with interfaces and object compostion. The
problem becomes one of assembling a lot of little objects.

Reflection is one way to handle this, so long as the assemblage
takes place infrequently. Jetty uses reflection to basically
build a server from component parts.

Assembling systems from components is great. Programming to interfaces
makes this relatively straightforward, and can also reduce or eliminate
the need to perform reflective method invocations.

Keeping in mind that, if you have a pluggable architecture, and
you want to be acommodating, reflection might worm it's way into
parts of the program. The design pattern is that of the
scriptable component.

Perhaps there's the crux: "want to be acommodating." By that I
interpret you to mean you do not want to demand that plugin components
implement any particular interface or extend any particular class. I
agree that requiring plugins to have some particular class as an
ancestor is inappropriately restrictive, but what's wrong with requiring
a suitable interface to be implemented? If someone is writing a plugin
for your application then it should be very little work to write it to
an API you specify. If someone is adapting an existing component to
your application then it need not be much more (or perhaps any more)
work to write an adapter class than it is to write a suitable
configuration file.

That properties file that says how to instanciate the Foo
plugin, might have also have a few lines on how to make it
frobnicate.

If your application can make use of a library that reflectively performs
generic "doSomething()" operations, then it could just as well make
normal use of reflectively instantiated objects that implement a generic
"SomethingDoer" interface. You have not persuaded me that you _need_ to
use reflection in this case, nor even that it is a significant advantage
to do so.

A JSP page will reflect every time it runs to invoke
the getters and setters on the partipating Beans.

JSP pages do not necessarily reflect when they use beans. Property
names can and should be matched with accessor methods at page
compilation time (via reflection-based Introspection). Even
<jsp:setProperty property="*"> can be compiled such that no reflective
method invocation is required, although perhaps that's a case where the
reflective solution is in fact warranted.

I'm not buying into these distinctions you are making. I don't
see applications as being a programming terminus, where parts of
the Java API off limits because they are too frameworky.

Any body of software will grow until the point where it is
pluggable (and can read e-mail).

You mistake my emphasis. I do not claim that any part of the Java API
is off limits to any application or application type. I claim that
heavy use of reflection is generally a poor design and / or
implementation choice.(*) If you have a body of software that requires
plugability of such magnitude that reflection is the only reasonable
option, then it _is_ an application framework. If you have anything
less, then one of the reasonable non-reflective alternatives is always
better.

* To qualify as making "heavy use of reflection" (according to me), an
application must perform reflective method invocation, not just
reflective instantiation or class introspection.

 

[John C. Bollinger]

I'm really trying to avoid a making a discussion of when to use
a necessary step before a discussion on how to use, so I'm going
to fork my response.

Very well.

Assume that I've made a valid decision to employ data-driven
reflection in to solve two separate problems.
Fine.

I've run into a number of tasks that are repetitions. I'd like
to encapsulate those tasks in a library.

Makes sense.

As far as what's wrong, the API I already have, the exception
heirarchy does not make the obvious distinction between erros in
reflection, and errors in the execution of a method invoked by
reflection.

Not in one neat package, agreed. Also agreed that those are the two
general categories of exception that you need to be concerned with.

I was thinking that I might create an error handler interface
that would be attached to a class loader, and that it would raise
unchecked exceptions, the sort that the application might
expect, but now a revised object heirarchy seems to make more
sense. One that would include more information about the failure.

I think you are leaning in the better direction.


John Bollinger
(e-mail address removed)

 

[alan]

Yes, basically. The name 'FileNotFoundException2' is obviously a
little brain-dead. You'd want something domain-specific that
describes the exception from a calling context, such as
FooFileNotFoundException. You'd possibly also want to include
more information about the details of the foo-file element that
referenced that file.

Fair enough.

I'm trying to sort through best practices. It doesn't seem like
Java programmers are too eager to create new exceptions for
their application, try to reuse existing ones.

I'd think that it would make sense for an project to define it's
open exception taxonomy, and to put some real thought into it.

I wouldn't put it that way. Instead, I'd say you are responsible
for ensuring that exceptions thrown from your code are useful in
the calling context. For all of the standard API routines that
throw FileNotFoundException, the exception is sufficient in the
calling context to identify all information about the exception
that occurred. If you intend to use it in some more elaborate
way, then you should use chaining and possibly your own exceptions
to be sure that it remains that way.

I don't understand what you're saying here.

I'm saying that with an observer pattern, the calling context is
hard to define.

I don't even seem to have the vocabulary to describe my
observations. There's a difference between backing out of the
call stack, restoring the state of objects called, restoring the
state of the caller, and then figuring out what to do next in
the program pass, fail, log, or retry.