How to correctly catch an exception if method uses method that throws an exception

Question

I've a question about catching an exception in method that use another method that can throw an exception.

public void methodA(File file) {
  try {
  }
  catch (IOException ex) {
  }
}

public void methodB() {
 // do something with the file
 File file = new File("/example.txt");
 methodA(file);
}

Do I need to create a try and catch block inside the methodB? Or it's enough to catch the exception in that case IOException inside methodA?

Possible duplicate of [Catching versus Throwing Exceptions in Java](https://stackoverflow.com/questions/31215951/catching-versus-throwing-exceptions-in-java) — Willem, Oct 01 '19 at 17:22
possible duplicate of: https://stackoverflow.com/questions/31215951/catching-versus-throwing-exceptions-in-java https://stackoverflow.com/questions/3241571/try-catch-versus-throws-exception https://stackoverflow.com/questions/23041570/throw-exception-inside-catch-clause — Willem, Oct 01 '19 at 17:23
`methodA` doesn't throw any exceptions so there is nothing for `methodB` to catch. — Moob, Oct 01 '19 at 17:23
I can't tell which method is actually doing something that will raise an IOException from the code above. The rule is, basically: Low-level methods should declare that they throw exceptions and not try to catch them. Handle exceptions at the highest level you can. So if `a` calls `b` calls `c` and `c` does something that may raise an exception, don't handle it in `c` or `b` (usually), handle it in `a`. — T.J. Crowder, Oct 01 '19 at 17:25
Can you do anything in `methodA` with the exception, where you would want methodB to continue even though `methodA` had the exception occur? If not, you should probably not handle the IOException in `methodA` but declare it to throw an exception and deal with it in `methodB` by similar logic, if you cannot handle the exception in methodB, then declare it to throw. — matt, Oct 01 '19 at 17:47

score 2 · Accepted Answer · answered Oct 01 '19 at 17:33

It depends on what you'd like to achieve.

In your code sample, methodA will handle an exception and continue a methodB execution with no interrupts. This is probably not what you'd like since there was an error reading file and it should be gracefully handled.

Most likely you'd like to bubble your exception up the execution chain and handle it in a relevant object (eg. some error handler that can output error message to an user) .

Bubble up your exception like this:

public void methodA(File file) throws CustomUserInputException {
  try {
  }
  catch (IOException ex) {
    throw new CustomUserInputException(ex, "Error opening file" + file.getPath());
  }
}

and then handle it in an approptiate object like this:

public void methodB() {
 // do something with the file
 File file = new File("/example.txt");
 try {
   methodA(file);
  }
  catch (CustomUserInputException ex) {
    showErrorToAnUser();
    stopStandardProgramExecution();
  }
}

score 1 · Answer 2 · edited Oct 01 '19 at 17:35

No, in this case you do not need to in methodB - but you might want to, because methodA might throw other errors beside IOException.

It depends on your intention and the type of exception - if your methodA throws a checked exception methodB has to either catch it or declare that it throws that exception. If its an RuntimeException, methodB might catch it or ignore it. In most techstacks, checked exception are rare, most think they are a failed experiment.

Lastly, whether a method needs to catch exception or not depends - can methodB conceivably handle the error? If so, catch it there - if not, let it bubble up, e.g. to a general error handler or even crash the program. nothing is more annoying than a program which catches every error and does the wrong thing.

score -1 · Answer 3 · answered Oct 01 '19 at 17:25

-1

You can't since the exception can only move up the callstack. If the program also ran methods following the exception, whats the point of even creating an exception in the first place?

Try to handle exceptions where they occour. If there is a possibility of an exception when creating a File, it should be handled where the file is created. Otherwise the overhead of making sure that incoming values are not exceptions would be way too high.

I would suggest either catching it inside methodBor passing the file name into methodA and have it create the File and catch any exceptions.

answered Oct 01 '19 at 17:25

Locke

2,041
12
26

1

"Try to handle exceptions where they occour." That's not correct. You want to handle exceptions where you actually can handle them in a meaningful way. That's not necessarily where it occurs. – Tom Oct 01 '19 at 17:33
Its more that I think exceptions shouldn't be sent off for processing. If an exception needs additional parsing/handling beyond a multi-catch it's likely that you shouldn't be using an exception. – Locke Oct 01 '19 at 17:44
The issue isn't the catch, the issue is __what__ you do in the catch. A simple `log.e(exception)` can be enough for small CLI tools, but not for real applications. – Tom Oct 01 '19 at 18:30
I think this that is out of the scope of this question. I was not advocating for minimalist catches, but instead commenting on how doing additional processing on an exception is starting to border on flow control. For example, prompting the user to re-select an input file from an `IOExcepton` versus piping the issue to another part of your code base. https://stackoverflow.com/questions/729379/why-not-use-exceptions-as-regular-flow-of-control – Locke Oct 02 '19 at 00:12

How to correctly catch an exception if method uses method that throws an exception

3 Answers3