I have an application that in one method calls two other methods respectively, and both methods may throw IOException and i like to catch them in caller method, but i don't know if there is something in Exceptions to tell about where it was thrown in the application.
I find a way, but don't think it is efficient! and am asking if there is some better/more standard strategy.
So i prepared a SSCCE :
I will be so thankful if anyone has a good idea about the matter.
The exception stack trace will tell you the call stack at the time of exception, including source code filenames and line numbers (if compilation is done with debug info switched on).
Java allows you to wrap exceptions so that you can know the root cause. Every Exception object can be created by specifying its root cause Throwable. So add this type of constructors to your exception classes:
and in the file IO code, throw exception this way so that the root cause IOException and its call stack are propagated up:
First about printing stackTrace: i know that,it's months I'm programming with Java ... I didn't mean debugging, and am sorry if didn't explain enough !
Second about construction with rootCause: that won't help me too.The parameter should be a Throwable, and in this case, both methods (possibly more than two methods in another case!) throw IOException, so both will have IOException as their rootCause, so what should i have to define two extra class as customExceptions !?
And again i mention i want to have a way to know where in the application the Exception thrown, not to have define one different Exception class per method to just show where it was thrown.
I think there would be some way to obtaining the stack trace elements....and maybe you wouldn't believe me that just at the moment i find the perfect answer by looking again into the method i just never took a look at the StackTraceElement class
after edition: I just correct my thanks to the answer of Karthik
Campbell Ritchie wrote:Go and read the documentation for IOException and you will find you have been given very useful advice about constructors.
I always read them first. I'm not sure constructing the Exception with its rootCause would make any difference to put me through the information about which method(s) the exception walked throughly.
StackTraceElement looks perfect for that (and i believe mentioning it by Karthik Shiraly directed me to look at it more precisely, so i appreciate again)
And consider this is a short example, and i wasn't talking about just IOException, i used that for an instance, i intended to pick a way to have programmatic access to one of several methods may throw same exception and all are calling from one method that catches this specified Exception
Don't you think this will be much more efficient (specially if we have many methods instead of two) ?
If not so, please tell me why i am wrong ?
If you had read the documentation properly, you would know that IOException is a Throwable, and can therefore be passed as an argument to a constructor. You would also have seen the printStackTrace() method. Karthik Shiraly has already shown you how you can wrap Exceptions in each other, and the simplest way to find the details of an Exception. I told you, you have been given some very useful suggestions. Why didn't you try them? It is probably unnecessary to create a new Exception with a cause at this stage, but printStackTrace() is much simpler than what you are doing. You may need to change to something more complicated later, but try the simple things first.
Esmaeil Ashrafi wrote:
Campbell Ritchie wrote:Go and read the documentation for IOException . . .
I always read them first. . . .
I think Campbell Ritchie is misunderstanding because of line #12 of code snippet in my last post,so why i didn't use simply the printStackTrace method?
Because i didn't intend to! this was just an example! and in the real case, instead of line #12, i need to put conditional check and make a distinct decision upon each method may throw the same exception, here IOException (something for method1 and something for method2).I didn't want to debug.
Both you are mentioning right things, but in my case, StackTrace is the exact solution. (at least i think this is)
Have a good day.
I tried to experiment this bad idea and fell in more troubles.I'd just intend to have two benefits:
To make the code more compact, that is: instead of putting the (almost) same code in each catch body of the thrower method of the same exception, put the cods in the catch body of the parent method calls consequently these thrower methods!
In the application i wrote, there are two methods being called by one initializer method. Each method catches FileNotFoundException, but in case of other IOExceptions, i just wanted to give another chance to the method to read the data (from properties file) again! (of course upon user decision),because i think the exception may throw just once! (or twice!), so in such conditions may not permanent, i ask the user to decide whether to apply defaults or try to read again by means of a dialog.Thus you see i need to know which method (each reads a properties file and do some other configuration staff) to call it again...and this was the whole story why i encountered this bad idea!
but there will be other troubles, like: if i call that specified method, there will need another catch or throw in the body of catch...
another: if i just catch the exception in each thrower method and recall that method (from within its catch body!), by to many calls may encounter the StackOverFlow...
Thereupon probably totally a wrong idea....
Any other suggestion will much appreciated