Reflection: Can you test for InstantiationException before attempting to instantiate?

Hi All.

Is it possible to determine if a class can be instanciated at runtime, or in other words check at runtime to see if using reflection to instanciate it will throw an InstantiationException?

I'm building an XML configurable plugin arcitecture:
I want to allow the user to create a template for instanciating a plugin in one part of the XML and reference it else where to create the actual instances. This directly translates into building a typesafe "PluginFactory" for each template and saving them for later use.

The difficulty is that the user may make a mistake and add a template for an abstract class or interface etc. I want to detect this when the "PluginFactory" is being created, not when it is first used.

You can check a class's modifiers to see if it is abstract (I believe that interfaces will be caught this way). You could also try to get the class's constructors via getConstructors(), catching for SecurityException. If the return is an array of 0 length, then it has no constructors (or is an array, or a primitive type or (?)void). Then you could iterate through any constructors present and call isAccessable() to see if they are available for use.

Quote:

---

detect this when the "PluginFactory" is being created, not when it is first used.

---

Quote:

---

user may make a mistake and add a template for an abstract class or interface

---

Could you do a trial run to detect it when the user enters the data?
Is this like the general problem of checking for valid user input?
Or catching an exception when the user has entered invalid input?

Why not let the Reflection framework do all the testing and catch the InstantiationException afterwards?

kind regards,

Jos

Quote:

---

Originally Posted by JosAH

Why not let the Reflection framework do all the testing and catch the InstantiationException afterwards?

kind regards,

Jos

---

Probably the safest way since there are other reasons why instantiation my fail and it is impossible to test all of them using reflection alone.

Quote:

---

Originally Posted by r035198x

Probably the safest way since there are other reasons why instantiation my fail and it is impossible to test all of them using reflection alone.

---

What can the other reasons be?

kind regards,

ps. long time no see.

Quote:

---

Originally Posted by JosAH

What can the other reasons be?...

---

That seems to be the big question. Spec says it's thron " ... if the instantiation fails for some other reason."
Seems safe to assume that not all those reasons can be tested for by reflection.

Quote:

---

Originally Posted by JosAH

ps. long time no see.

---

Yes, my belly button and various other parts of the anatomy are still as cute as ever.

Quote:

---

Originally Posted by r035198x

That seems to be the big question. Spec says it's thron " ... if the instantiation fails for some other reason."
Seems safe to assume that not all those reasons can be tested for by reflection.

---

If the Reflection code can't test it then you can't test it; e.g. an Exception thrown from the constructor of that class ...

Quote:

---

Originally Posted by r035198x

Yes, my belly button and various other parts of the anatomy are still as cute as ever.

---

Oh dear ... ;-)

kind regards,

Jos

Quote:

---

Originally Posted by r035198x

Probably the safest way since there are other reasons why instantiation my fail and it is impossible to test all of them using reflection alone.

---

The InstanciationException covers a specific subset of causes for failing to load a class. Many (though not all) can be identified before the fact. Granted some of them are runtime specific.
I'll limit things here a little by saying I'm only interested in those causes which would detected by the compiler if reflection wasn't being used in this project.
I have to add a catch statement anyway, so the unknowns which can't be helped aren't likely to be much of an issue.

Why not just catch it when the invocation fails?
Well the first and simplest answer is because it provides the correct stack trace that caused the issue rather than the stack trace from when the issue was found.
It shows where and why the Template was created instead of simply where it was used first.
That makes it MUCH easier to debug where templates are coming from multiple overlapping sources.

Secondly, a template being accessed by another template could fail and cause a cascading set of templates fail.
If the issue is identified before the template is used then there is at least some change of recovering (logging appropriate errors) and continuing with everything else.

Thirdly. Because.