When should we throw exceptions, or catch exceptions, in a method?

Question

I've been reading up more on exceptions, but I am not sure with what cases we should either throw a method

public void fxml() throws IOException
{
     // method body here
}

or catch an exception within a method

public void fxml()
{
          FXMLLoader fxmlLoader = new FXMLLoader(getClass().getResource("fxml.fxml"));

            try
            {
                fxmlLoader.load();
            } 
            catch (IOException exception) 
            {
                throw new RuntimeException(exception);
            } 
}

From Oracle's example it says

Sometimes, it's appropriate for code to catch exceptions that can occur within it. In other cases, however, it's better to let a method further up the call stack handle the exception. For example, if you were providing the ListOfNumbers class as part of a package of classes, you probably couldn't anticipate the needs of all the users of your package. In this case, it's better to not catch the exception and to allow a method further up the call stack to handle it.

https://docs.oracle.com/javase/tutorial/essential/exceptions/declaring.html

So I'm curious if this is saying that we might not need the class/method and by doing a try/catch inside this method it doesn't serve a purpose if we don't use it, so we "throw it" for later use?

It seems that classes themselves also "throw exceptions" in order to be used later... Is it just a hierarchy of throws until you can finally use it all? In the tutorial above, a few chapters later is a chapter called "Chained Exceptions" is this essentially what's going on with the method throws for use later?

I also read this thread When to use throws in a Java method declaration?

but I found it didn't fully explain what I wanted to know, however I found this interest

If you are catching an exception type, you do not need to throw it, unless you are going to rethrow it. In the example you post, the developer should have done one or another, not both.

Typically, if you are not going to do anything with the exception, you should not catch it.

The most dangerous thing you can do is catch an exception and not do anything with it.

I'm not really sure what he meant by "rethrowing" it unless he's speaking about throwing the method and catching it later?

Then he talks about not doing anything with an exception if you're not going to use it, so it seems throwing it for later use is preferred in case we need it?

Then talking about it being dangerous? Why is this?

So essentially if we don't know if we are going to use it, then we should throw it so the method itself can be called, or if we know that it's going to be called, no matter what, then we should do a try/catch block?

I also notice that my example also throws a RuntimeException based on the IOException. So in a sense you could take the first method we threw with whatever exceptions, and then throw it in either the try OR catch block? It seems the catch block is more suited for "RuntimeException" or one of those other system exceptions, but maybe there are other usecases?

Thoughts?

Thanks for the help!

A lot comes down to the expectations of the caller. If the caller is relying on the results of the method call, it would be advantages to throw/rethrow the exception(s), so that they know when the results have been invalidated. This will also come down to the amount of control the method has, for example, if the method is load a configuration file, does the method have the ability/control to effect the rest of the program, or is it isolated/decoupled from the rest of the program? — MadProgrammer, Oct 15 '15 at 00:13
As one would expect, this question, or one similar to it, has been [asked many times on this site](https://www.google.com/search?q=java+when+to+throw+exceptions+when+to+catch&rlz=1C1ASUT_enUS496CA496&oq=java+when+to+throw+exceptions+when+to+catch&aqs=chrome..69i57.11970j0j7&sourceid=chrome&es_sm=93&ie=UTF-8#q=java+when+to+throw+exceptions+when+to+catch+site:http:%2F%2Fstackoverflow.com%2F). — Hovercraft Full Of Eels, Oct 15 '15 at 00:15
This is not the same as asking whether to have a `throws` part in the method signature. Doing that would be asking whether to throw a *checked* exception. — Raedwald, Oct 12 '17 at 07:51

score 6 · Accepted Answer · answered Oct 15 '15 at 00:13

You throw an exception if your code can't do its job (also known as "fulfilling its contract"). This might happen because the caller passed you invalid input, or some external resource is malfunctioning (such as a lost network connection).

Catch an exception when there's an anticipated problem downstream that you can handle somehow. For example, you might catch exceptions indicating network problems and retry the operation a couple of times, or you might display an error message to the user and ask what to do next.

If downstream code might throw an exception but your code is somewhere in the middle and doesn't know what to do, just let the exception travel up to the calling code.

When should we throw exceptions, or catch exceptions, in a method?

1 Answers1

Linked

Related