0

Everytime I encounter a java exception ,I always fell into the dilemma whether I should throw the exception directly or catch the exception .If I catch the exception ,should I just print the stack trace or do more work in the catch block?For example , I am a reading a file line by line,the function BufferedReader.readLine() throws an IOException ,it seems that it is an checked(compared with unchecked exception) Exception because user was told to deal with this exception explicitly,right?Although I have to deal with it , but it seems that I can do nothing else but print stack trace, well ,it is really strange.Should I catch or throw this exception? If I catch it,what should I do in catch block?

wuchang
  • 3,003
  • 8
  • 42
  • 66
  • Read the section title "Catch Late" on this page: https://today.java.net/pub/a/today/2003/12/04/exceptions.html And this stack overflow answer: http://stackoverflow.com/questions/3551221/guidelines-on-exception-propagation-in-java – Keith Sep 04 '13 at 01:53

3 Answers3

0

Its not about only printing the stacktrace,

  • You can put the exception info in separate log
  • In case of exception you can close and delete the file if you are writing or whatever you want.

If you duck the exception, the calling method will have to handle it.

Prasad Kharkar
  • 13,410
  • 5
  • 37
  • 56
0

You can do the following things:

  1. Log the Exception information on a log file. You can use the following method to populate the Exception information.

    public String populateExceptionStackTrace(Exception e) { StringBuilder sb = new StringBuilder(); sb.append(e.toString()).append('\n'); for (StackTraceElement elem : e.getStackTrace()) { sb.append("\tat ").append(elem).append('\n'); } return sb.toString(); }

  2. Try to close the InputStream if it is not null.

  3. Throw an Exception of your own with meaningful message to let user know what happens.

user207421
  • 305,947
  • 44
  • 307
  • 483
Mengjun
  • 3,159
  • 1
  • 15
  • 21
0

This is about which part is responsible for this Exception.

If, for example, you're developing a tool package as a jar, maybe you should just throw the IOException in a method like PrasadIOUtils.ReadFile(String path), which should just provide the function to read a file, not to handle the exception.

In contrast, you should catch the Exception when you invoking method PrasadIOUtils.ReadFile(String path) in your code. Because this is your logic part, and you are the one who is responsible for handling the Exception to make your own project more robust and fault-tolerant.

This is just How I understand, hope it helps. :)

P.S. If you're still confused about there's nothing to do but printing the expection's stack trace, you can google exception chaining for further information. This is a java design pattern, maybe it'll make you understand more on Exception.

Judking
  • 6,111
  • 11
  • 55
  • 84
  • Yep. Let me generalize that. In each case you must consider the contract of the method you are in (what is it supposed to do). If, after IOException is thrown, that method can *still* do what it is supposed to do, then catch it and fulfill the method contract. If after IOException is throw there is no way the enclosing method can do what it is supposed to do then let the exception propagate. So, continuing the example above readFile() is just supposed to read the file, it should throw if it cannot. Period. But a higher level method readFileIfPossibleOrShowDialog() would have to catch. – Keith Sep 04 '13 at 02:09