CODEWITHSUNDEEP
javaexceptiontry-catchthrows
user16655
user16655

Reputation: 1941

Exceptions - inheritance

Let's say I have defined my own Exception (eg. 'MyException'), and also have these methods:

    public String myMethod3() throws MyException {

    try {
        methodThatAlwaysThrowsException();
    } catch (Exception e) {
        MyException me = new MyException("Exception!");
        throw me;
    }

    return "myMethod3";
}

public String myMethod2() throws MyException {

    String str = myMethod2();
    return "myMethod2 " + str;
}

public void myMethod1() {

    String str = null;

    try {
        str = myMethod2();
    } catch (MyException e) {
        e.printStackTrace();
        str = "Exception caught";
    }

    System.out.println(str);
}

Have I understood it correctly that when an Exception is thrown in 'methodThatAlwaysThrowsException', it wil be caught and throw MyException. MyMethod2() will then just throw it again back to myMethod1() which will catch it, and 'Exception caught' will be written?

More specifically, when an error is thrown in a method, and the methods 'above' it also just throws the error, it won't be caught until you have a try/catch (or the main method throws it)? I am looking at some code with a deep hierarchy, where an exception is thrown maybe 5-6-7 methods, and then caught. Is this a good way to handle Exceptions? To me it seems like the error should be caught right away. Is there a good reason to throw them like this?

Upvotes: 0

Views: 232

Answers (2)

hagrawal7777
hagrawal7777

Reputation: 14668

More specifically, when an error is thrown in a method, and the methods 'above' it also just throws the error, it won't be caught until you have a try/catch (or the main method throws it)?

Yes. Read below following from JLS §11.3. Run-Time Handling of an Exception and more from that link ...

So:

  • If you will not catch the exception then exception will propagated till main thread and main thread will terminate.
  • If you catch the exception and do re-throw it then subsequent blocks of code in the method will be executed (please read JLS link I hv provided for more details).
  • If you catch the exception and re-throw it then it will be propagated to caller of that method.

From JLS:

If no catch clause that can handle an exception can be found, then the current thread (the thread that encountered the exception) is terminated. Before termination, all finally clauses are executed and the uncaught exception is handled

When an exception is thrown (§14.18), control is transferred from the code that caused the exception to the nearest dynamically enclosing catch clause, if any, of a try statement (§14.20) that can handle the exception.


Your question:

Is this a good way to handle Exceptions?

Yes, exception should be handled using try-catch-finally

To me it seems like the error should be caught right away. Is there a good reason to throw them like this?

Yes, you should re-throw it so that it is can be captured by a Application Performance Monitoring (APM) tool like DynaTrace. If you catch the exception and simply eat it then these kind of APM tools will not be able to find it and hence will not generate any report.

So, from Application Performance Monitoring (APM) tools perspective it is good practice that you throw a exception, you may catch it again and do whatever you want, but throw it once.

Upvotes: 1

Jaroslaw Pawlak
Jaroslaw Pawlak

Reputation: 5588

It really depends on the component and why the exception is thrown, here are a few examples of how exception can be dealt with in different circumstances.

Don't catch it

In RESTful application you can register ExceptionMapper, every exception thrown will be passed into this class and converted into response depending on how mapper handles this exception. So if we don't care (don't expect) an exception, we don't catch it. If it is a checked exception, we convert it into RuntimeException and re-throw it.

Ignore it

Let's say we have a server-side cache to avoid costly access to the database. Cache is updated every 5 minutes. If the refresh fails, we still want to try again in 5 minutes in which case we just log the exception but don't do anything else in the catch block.

Handle it

In cases when you want to handle exception, I would recommend to handle it as soon as possible. For example, the GUI application tries to override an existing file, but it fails (probably file is locked by another process). We may have a feature that in such cases saves it to different file. In this case the sooner you catch the exception, the easier the code will be to understand - because you will not have to browse through 5 files to find out what happens with this exception.

Upvotes: 0

Related Questions