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.
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?
Isn't it funny how there's always time and money enough to do it WRONG?
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.
Joined: Aug 16, 2010
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,
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.
Error triggering call to MCMB
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.
Joined: Aug 16, 2010
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:
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:
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 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.
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?