Search code examples
javaejbmethod-invocationinvocationtargetexception

How to Catch Invocation Target Exception?


I have following piece of code:

try
      {
          glogger.debug("Calling getReportData (BudgetInBriefDAO)");
          lHashData = objBudgetInBriefDAO.getReportData(lStrFinYrId, lStrLangId, lStrContextPath, lStrFinYrDesc);
          glogger.debug("Returning from getReportData (BudgetInBriefDAO)");
      }
//      catch( InvocationTargetException ie )
//      {
//          glogger.error("InvocationTargetException !!!");
//          glogger.error("InvocationTargetException in calling BudgetInBriefBean -> getReportData");
//          glogger.error("Target Exception is : " + ie.getTargetException());
//          glogger.error("Cause is : " + ie.getCause());
//          ie.printStackTrace();
//      }
      catch( Exception e )
      {
          glogger.error("Exception !!!");
          glogger.error( "Error in calling BudgetInBriefBean -> getReportData. Error is :- " + e );
          e.printStackTrace();
      }

I am getting following Error:

FATAL : AJPRequestHandler-ApplicationServerThread-25 com.tcs.sgv.common.util.GenericEJBObject - InvocationTargetException :java.lang.reflect.InvocationTargetException - 14 Feb 2012 12:36:00,155 - 5210474 milliseconds

It is not printing Stack Trace. How would I know the Cause of the Exception ?

I have uncommented code & still not getting the Stack Trace printed.

Between, my BudgetInBriefDAO Implementation (BudgetInBriefDAOImpl) contains 4 classes.

BudgetInBriefDAOImpl & 3 other Thread classes

I have decompiled all the class file successfullly without corruption.

Please help to find out Actual Cause of Exception.

Thanks in advance.


Solution

  • Try to decompile com.tcs.sgv.common.util.GenericEJBObject; maybe it swallows the exception.

    Alternatively, start the app in debug mode and set a break point in all the constructors of InvocationTargetException.

    Note: This might turn out to be impractical because other code causes a ton of these exceptions long before you get to the place you want to debug. If that happens, disable these breakpoints, add a new breakpoint at the first glogger.debug and enable the exception's breakpoints again when this one is hit.

    When you have stack trace in your debugger, set a breakpoint in the place where the exception is thrown before doing anything else.

    Last option: Set a breakpoint in glogger.fatal (or the place where the exception is logged).