aspose file tools*
The moose likes Java in General and the fly likes How to determine the type of exception thrown by a method. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "How to determine the type of exception thrown by a method. " Watch "How to determine the type of exception thrown by a method. " New topic
Author

How to determine the type of exception thrown by a method.

Robinson Francis
Greenhorn

Joined: Aug 16, 2010
Posts: 22
Hi there everyone,

I have a code which is designed to catch two types of exeption:

  • EBufException (from com.portal.pcm.EBufException)
  • Exception e.


  • The code is as below.




    These methods in the code are designed to catch error of type EBufException:

    Vector NodeLocation = ProductUtil.getNodeLocation(ctx, accountPoid, dealPoid);
    returnFlist = opcode.opcode(ctx, PortalOp.BILL_CANCEL_DEAL, PortalContext.OPFLG_READ_RESULT, inputList);

    But if there is any other exception type then it would be propagated to this method terminateDeal(.....) which calls them and it is later caught by Exception e block (I guess). My question now is how can I detrmine the type of error thrown if it is caught by Exception e catch block.


    Thank you all in advance.




    Rob Spoor
    Sheriff

    Joined: Oct 27, 2005
    Posts: 19693
        
      20

    Please KeepItDown. That also applies to your subject lines. Also, try to prevent lines that are too long in your code, as it will mess up the forum layout. I've split two lines to lessen this problem.

    Any object, including exceptions, have an associated Class object which you can get using getClass(). This tells you the exact type.


    SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
    How To Ask Questions How To Answer Questions
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 7781
        
      21

    Robinson Francis wrote:But if there is any other exception type then it would be propagated to this method terminateDeal(.....)
    which calls them and it is later caught by Exception e block (I guess).
    My question now is how can I detrmine the type of error thrown if it is caught by Exception e catch block.

    Rob's already answered your question, but my concern is: Why do you think you need to know?
    What do you hope to gain by knowing the type of exception thrown that couldn't be catered for by additional catch blocks?

    Winston


    Isn't it funny how there's always time and money enough to do it WRONG?
    Articles by Winston can be found here
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 38818
        
      23
    Rob Spoor wrote: . . . lines that are too long in your code, as it will mess up the forum layout. I've split two lines to lessen this problem. . . .
    I have split a few more lines for the same reason.
    Robinson Francis
    Greenhorn

    Joined: Aug 16, 2010
    Posts: 22
    First of all thank you for your all answers.

    The reason I am trying to know te exception class, is that I want to handle exception that is thrown properly. By properly, I mean I need to send it to a portion of code that will recall this portion of the code, In this code,

    methods, getNodeLocation() and opcode() in lines

    Vector NodeLocation = ProductUtil.getNodeLocation(ctx, accountPoid, dealPoid);

    and

    returnFlist = opcode.opcode(ctx, PortalOp.BILL_CANCEL_DEAL, PortalContext.OPFLG_READ_RESULT, inputList);

    Are defined to throw an EBufException, but I do not know why the catch block for for _____ is the only one catching the error. Anyway I have found out from the stack trace that the exception thrown out is of type NullPointerException.



    Caused by:
    com.tm.hsbb.eai.archcomp.exception.AbstractExternalErrorRuntimeException:
    Error triggering call to MCMB

    Caused by:
    java.lang.NullPointerException:
    null</response_error_message>


    How do I determine where this exception is being thrown by the code? Is there any suggestion on finding out the exact location?

    I have a hunch that it could be due to this line of statement:

    In this class we have to obtain a context to the target server using this method:


    The full code of this method getMCMBContext() is



    The statement



    opens a communication channel between a client application and the Portal server. Connection is made by opening an Portal context.

    I suspect that this could be the place where the NullPointerException is thrown. I am not sure but can you clarify.

    Thank you.

    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 7781
        
      21

    Robinson Francis wrote:How do I determine where this exception is being thrown by the code? Is there any suggestion on finding out the exact location?

    That information is included in the stacktrace. However, the real issue you're confronting is common to many NullPointerException failures: the fact that the exception doesn't occur at the point where it was caused.

    Unfortunately, there's very little you can do about it other than following good defensive practices yourself (checking all parameters before use, returning an appropriate value rather than null, good documentation... etc, etc). Of course, that doesn't help you much if you're dealing with code written by someone who didn't.

    Knowing what the Exception is isn't likely to help you solve the problem; and will probably just add a lot of "noise" code.

    Winston
    Robinson Francis
    Greenhorn

    Joined: Aug 16, 2010
    Posts: 22
    Thank you for your opinion, the problem here is that this code is part of a EAI application. If the nullpointer exceptions occur once for a transaction, the transaction gets stuck that's where we get the stack trace. But the exception doesn't appear if we retrigger the transaction. So it seems intermittent. The suspicion is falling on these two methods:


    and


    another one is



    These lines make a call to a server which is always busy and some times they get disconnected and thus they cannot establish a connection to it.

    The problem is that the stack trace ends here in this block of code but it doesn't go further:

    Caused by:
    com.tm.hsbb.eai.archcomp.exception.AbstractExternalErrorRuntimeException
    at com.tm.iCarePrime.eai.adapter.mcmb.McmbAdapter.handleException(McmbAdapter.java:1271)
    at com.tm.iCarePrime.eai.adapter.mcmb.McmbAdapter.terminateDeal(McmbAdapter.java:1072)
    at com.tm.hsbb.eai.buscomp.billing.adaptor.brmrules.BrmRules.brmSvcLvlGenericOliTerm(BrmRules.java:528)
    at com.tm.hsbb.eai.buscomp.billing.adaptor.siebelrules.SiebelRules.svcLvlGenericOliTerm(SiebelRules.java:97)
    at com.tm.iCarePrime.eai.buscomp.billing.adaptor.OrderBillingProvisioningDriver.activateBilling(OrderBillingProvisioningDriver.java:298)
    at com.tm.iCarePrime.eai.archcomp.BEhandler.ImplClass.BillingUtilityAsyncBusEventMsgHandler.mainlogic(BillingUtilityAsyncBusEventMsgHandler.java:214)
    at com.tm.hsbb.eai.archcomp.messagehandler.SimpleAsyncBusEventMsgHandler.handleBusinessEventMessage(SimpleAsyncBusEventMsgHandler.java:56)
    at com.tm.hsbb.eai.archcomp.messagehandler.BusinessEventMessageHandler.handleMessage(BusinessEventMessageHandler.java:130)
    at com.tm.hsbb.eai.archcomp.serviceMapper.ResumeProcessingServiceMapperImpl.processMessage(ResumeProcessingServiceMapperImpl.java:74)
    at com.tm.hsbb.eai.archcomp.messagereceiver.JMSMessageReceiver.onMessage(JMSMessageReceiver.java:99)
    at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:531)
    at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:466)
    at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:435)
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:316)
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:255)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:927)
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:851)
    at java.lang.Thread.run(Thread.java:619)


    So I know it is in the terminateDeal method(the method I pasted in the first post), but I don't know further. I just want to ask you this question. In this terminateDeal method, there is a call to this method getMCMBContext() and if you see the code which I posted recently(@ Yesterday 23:27:26 ), it has been configured with a catch block to throw RuntimeException,

    refer to lines 16-18




    My question is, if the exception that is thrown by line 15

    is :

    is of type EBufException, will it be ignored. and be allowed to propagate to the calling method?

    Secondly, if the exception of type RuntimeException is thrown to calling method terminateDeal, its going to be handled by



    right? So what happens to the message "MCMB Connection not initialized!" that is sent to the constructor RuntimeException? does it get displayed? Because in the final stack trace only "Error triggering call to MCMB" is being displayed.

    Can you help me on this?Thank you.



    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 7781
        
      21

    Robinson Francis wrote:Thank you for your opinion, the problem here is that this code is part of a EAI application. If the nullpointer exceptions occur once for a transaction, the transaction gets stuck that's where we get the stack trace. But the exception doesn't appear if we retrigger the transaction. So it seems intermittent.

    I don't follow. Is this is a piece of 3rd party software? It would appear that you're making an awful lot of calls to something called MCMB, and that the error is occurring deep in its code. Do you know what an AbstractExternalErrorRuntimeException is (it seems a remarkably unspecific name for such a mouthful), and was there any diagnostic message that came with the exception?

    If the underlying cause is a NullPointerException then something is plainly null, but with this number of unknowns, it's difficult to give any advice beyond following the chain of calls and reading the API documentation for each one carefully. Failing that, have you tried talking to the authors of the software?

    Winston
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: How to determine the type of exception thrown by a method.