Results 1 to 9 of 9
  1. #1
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default 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.
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

  2. #2
    Fubarable's Avatar
    Fubarable is offline Moderator
    Join Date
    Jun 2008
    Posts
    19,316
    Blog Entries
    1
    Rep Power
    25

    Default

    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.

  3. #3
    Norm's Avatar
    Norm is offline Moderator
    Join Date
    Jun 2008
    Location
    Eastern Florida
    Posts
    16,574
    Rep Power
    23

    Default

    detect this when the "PluginFactory" is being created, not when it is first used.
    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?

  4. #4
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,000
    Blog Entries
    7
    Rep Power
    20

    Default

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

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  5. #5
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    7

    Default

    Quote Originally Posted by JosAH View Post
    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.

  6. #6
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,000
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by r035198x View Post
    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.
    cenosillicaphobia: the fear for an empty beer glass

  7. #7
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    7

    Default

    Quote Originally Posted by JosAH View Post
    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 View Post
    ps. long time no see.
    Yes, my belly button and various other parts of the anatomy are still as cute as ever.

  8. #8
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,000
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by r035198x View Post
    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 View Post
    Yes, my belly button and various other parts of the anatomy are still as cute as ever.
    Oh dear ... ;-)

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  9. #9
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default

    Quote Originally Posted by r035198x View Post
    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.
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

Similar Threads

  1. Cannot instantiate a type
    By Yeshol in forum Eclipse
    Replies: 14
    Last Post: 07-06-2011, 05:03 PM
  2. Replies: 0
    Last Post: 12-13-2010, 06:52 PM
  3. Replies: 2
    Last Post: 11-21-2008, 08:36 PM
  4. [SOLVED] Unable to instantiate class?
    By xcallmejudasx in forum New To Java
    Replies: 1
    Last Post: 11-03-2008, 04:03 PM
  5. Attempting to make a Law of Sines program
    By taco89 in forum New To Java
    Replies: 1
    Last Post: 02-14-2008, 04:10 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •